SuperCPU for the Vic-20

[Radical Brad]

Great work!

I had similar timing issues on my project, and have been wathcing your progress with great interest.

It's ironic how "fussy" VIC-20 timing can be. Normally I use exclusevely non-blocking, and have never had any problems, even in my bleeding edge HDMI projects running the Spartan up to 300MHz! But in my current project (interfacing to VIC expansion port), I banged my head on the wall to get timing correct! I also had to resort to blocking, and a complext timed/debounce module for IO lines.

My Spartan-6 is running at 57.273MHz, and I had to create debounce timers for catching the HI and LO edges of PHI-2 in order to get everything to work glitch free. Even at 57MHz, a count difference of more than 2 cycles is enough to get the odd lost byte.

Keep up the great work.
Looking forward to more photos.

Cheers,
Brad

[Kakemoms]

It's ironic how "fussy" VIC-20 timing can be. Normally I use exclusevely non-blocking, and have never had any problems, even in my bleeding edge HDMI projects running the Spartan up to 300MHz! But in my current project (interfacing to VIC expansion port), I banged my head on the wall to get timing correct! I also had to resort to blocking, and a complext timed/debounce module for IO lines.

My Spartan-6 is running at 57.273MHz, and I had to create debounce timers for catching the HI and LO edges of PHI-2 in order to get everything to work glitch free. Even at 57MHz, a count difference of more than 2 cycles is enough to get the odd lost byte.

Nice to hear that we had similar experiences. I think the lower slew rate between high and low confuses the fpga logic. It is easily viewable on the buses (lines switch at different times), but the clock signal will obviously not show this, even when it misses an edge.

Anyway, it works now IRL, so I can focus on other things (after holidays end). I hope the findings also help other 8-bit developments - its certainly not obvious to get around such problems.

[groepaz]

t's ironic how "fussy" VIC-20 timing can be.

vic20 has rock stable timing - try a C128

[Kakemoms]

Home again from hot days in italy and after a couple of fixes on color output, the game "THE TOMB oF DREWAN" seems to run quite ok.

The VGA screen:

The captured VIC output:

The improvement is most obvious on light colors and colors that clash. There is still a byte that is missing on the VGA, so a small bug there... but the game runs and is playable.

[Radical Brad]

Congrats... a great milestone!

...Exploding Kittens?

Brad

[Kakemoms]

I have started work on the SD Card interface and will use some 6502 code for the FAT32 (so thats more or less sorted out). For the SPI interface I have made an implementation in Verilog, but it requires a 1KiB buffer to be efficient (e.g. DMA). The question then becomes were to put the memory. I could keep the whole implementation on the 65C02 side, but since it will also be used to load Vic-20 programs into the internal memory, a better way would be to put it at IO2 or IO3 location. The problem with this apparently becomes compability. If you want to plug in several cartridges at once (for some reason), I have the impression that there are a few that needs the IO2 or IO3 for special registers.

Could anyone comment on this? Is the IO2 or IO3 possible to use (even temporarily) without sacrificing compability?

[Mike]

Could anyone comment on this? Is the IO2 or IO3 possible to use (even temporarily) without sacrificing compability?

Simply don't bother about other cartridges.

It's your cartridge that defines what has to be there and what is needed as registers in I/O 2 and I/O 3. That's what these address ranges are for.

That being said, there's no protocol or anything like that *) which defines a concurrent usage of two or more cartridges **), so there ...

Greetings,

Michael

*) like, a "list of assigned I/O address ranges", maintained by some authority.

**) except when those map in RAM or ROM. Then it should go without saying that two cartridges should not map memory into the same BLKx or RAMx range.

[Kakemoms]

Some more updates:

I decided to use IO2 area as a DMA buffer for the SPI interface for the SD Card. It has been quite hard to get this working, but I finally got the SDCard to respond.

It may not look like much:

What you see here are the actual signals on the SPI bus. At initialization, the SPI clock had to be slowed down, so it runs at 200kHz. The SPI output is composed from bits from data that is stored in the $9800-9BFF area (starting at $9800). What is really great here is that the SPI_input line goes high, then low (in the middle of the picture). That low signal (7 bits low, then 1 bit high) is the "acknowledged, idle" signal from the SD Card itself. Which is what I have tried to get for a week!

How this works:
SD Card commands are sent over the SPI bus using the memory from $9800 (and onwards for up to 1024 bytes). Since this is a DMA functionality, the 6502 starts the transfer by writing to $97FF (which is actually in the color memory, but unused since the screen only contains 506 bytes). The SuperVixen grabs the value that goes into $97FF and uses bit7-1 as length (bytes*8) and bit0 as directional register. There are also special poke values of 254 to set SPI bus into high speed mode (25MHz) and 255 to stop the SPI clock (and go back to init). All was made in Verilog to be as fast as possible.

Thus, memory transfer of 512bytes (normal FAT32 length) goes independent of the 6502 and at 25Mbit/s (=3,1Mbyte/s). At loading, the slowest part will be to copy the bytes from the buffer into the internal Vic-20 memory (around 100kbyte/s), while the expansion memory can use the 65C02 at around 2,5Mbyte/s.

All-in-all it means that a 28KiB program could (in theory) load from $1000 to $1FFF in 0,04seconds and from $2000 to $7FFF in 0,01seconds. E.g. in half the time it takes to display a frame on the screen. In practice, the SDCard may take some more time for certain tasks, but I don't think you are going to notice.

[Radical Brad]

Great progress again!

Are you going to fully implement FAT32?
I would be interested in seeing that work as 6502 code.

When I added SD to my other project, FS seemed like so much overhead that I ended up using RAW format, and made a PC program to write to the card as one giant 2GB binary. A simple file system had a fixed number of entries starting at sector 0, and the VIC looked there.

Keep up the good work.

Brad

[Kakemoms]

Great progress again!

Are you going to fully implement FAT32?
I would be interested in seeing that work as 6502 code.

When I added SD to my other project, FS seemed like so much overhead that I ended up using RAW format, and made a PC program to write to the card as one giant 2GB binary. A simple file system had a fixed number of entries starting at sector 0, and the VIC looked there.

Keep up the good work.

Brad

Interesting. How do you initialize your card and at what frequency? Do you speed it up after initialization? I use SDHC cards.

[Radical Brad]

My SD system as all done in code by an AVR, which was memory mapped to the rest of the system.

Initialization was at 400KHz, and then I could speed up a lot more. Some cards faster than others. I never did settle on a top speed, ans planned to make some type of "auto speed detect" code to determine this automatically. 4Mhz was certainly safe.

The VIC would issue bytes to IO3, where the AVR would be listening. This was my file system.
Functions were very basic...

Code: Select all

// TX COMMAND(8)				TX PARAMETER				RX DATA
// ------------------------------------------------------------------------------------------------------------------
// MOUNT VOLUME				NONE					RESULT(8),TEXT(16)
// LOAD DIRECTORY				NONE					LENGTH(24),DATA(?)
// LOAD FILENAME				TEXT(16)				        LENGTH(24),DATA(?)
// SAVE FILENAME				TEXT(16),LENGTH(24)		RESULT(8)
// RENAME FILENAME			TEXT(16),TEXT(16)			RESULT(8)
// ERASE FILENAME				TEXT(16)					RESULT(8)

The giant 2GB binary was accessed at the low level by the PC, making file table entries in a fixed length segment at the beginning of the binary. It works very well, is fast, but not compatible with a PC file system at all.

I may try using FAT-32 for the project I am currently doing.
Since I am only allowed to use 1980's logic, I would just make the AVR+SD an external serial device, and let my logic board talk to it via serial commands. That way, I can talk to whatever mass media flavor of the day is easiest to use.

Brad

Great progress again!

Are you going to fully implement FAT32?
I would be interested in seeing that work as 6502 code.

When I added SD to my other project, FS seemed like so much overhead that I ended up using RAW format, and made a PC program to write to the card as one giant 2GB binary. A simple file system had a fixed number of entries starting at sector 0, and the VIC looked there.

Keep up the good work.

Brad

Interesting. How do you initialize your card and at what frequency? Do you speed it up after initialization? I use SDHC cards.

[Kakemoms]

My SD system as all done in code by an AVR, which was memory mapped to the rest of the system.

Initialization was at 400KHz, and then I could speed up a lot more. Some cards faster than others. I never did settle on a top speed, ans planned to make some type of "auto speed detect" code to determine this automatically. 4Mhz was certainly safe.

The VIC would issue bytes to IO3, where the AVR would be listening. This was my file system.
Functions were very basic...

Code: Select all

// TX COMMAND(8)				TX PARAMETER				RX DATA
// ------------------------------------------------------------------------------------------------------------------
// MOUNT VOLUME				NONE					RESULT(8),TEXT(16)
// LOAD DIRECTORY				NONE					LENGTH(24),DATA(?)
// LOAD FILENAME				TEXT(16)				        LENGTH(24),DATA(?)
// SAVE FILENAME				TEXT(16),LENGTH(24)		RESULT(8)
// RENAME FILENAME			TEXT(16),TEXT(16)			RESULT(8)
// ERASE FILENAME				TEXT(16)					RESULT(8)

The giant 2GB binary was accessed at the low level by the PC, making file table entries in a fixed length segment at the beginning of the binary. It works very well, is fast, but not compatible with a PC file system at all.

I may try using FAT-32 for the project I am currently doing.
Since I am only allowed to use 1980's logic, I would just make the AVR+SD an external serial device, and let my logic board talk to it via serial commands. That way, I can talk to whatever mass media flavor of the day is easiest to use.

Ok! Was the 4MHz limit due to the AVR? I guess it is way too fast to be noticeable anyway.

Interesting file system. I am using FAT since it makes file transfer easier. Most people have some kind of PC or Mac they want to use.

[Kakemoms]

Well, after some work to translate FAT32 to 6502 and the SuperVixen interface, it is now more than 90% ready. There are a few bugs and the actual LOAD implementation needs some more work. The total size of the code is currently around 5K, so it will fit nicely inside a 8KiB block.

In order to free up space on the Vic-20 side, the whole code will be copied into a SRAM page that can be flipped in/out of BLK5. IO2 is used as a buffer for the SPI to SDCard interface (running @25Mbit). Currently all FAT32 code runs on the 6502 side, which makes the 65c02 totally free for other work. There is a plan behind that in which I hope to mirror the whole Vic-20 memory map into the 65c02 sometime in the future...and then run Basic programs on the side 65c02 as well. That is the long-term idea anyhow... should be interesting for all the Basic enthusiasts.

The limit of the FAT32 interface is (currently) one block per file. With 256KiB blocks, that gives space for 30000+ files on a 8GB card. 256KiB should be large enough to (later) support D64 files and whatever other files one needs.

Thanks to Thomas @Steckschwein for providing the original FAT32 code in 65c02 format. Their contribution to the 6502 platform is nothing short of phenomenal.

[Kakemoms]

The SPI interface has shown to be a troublesome beast, but it is now fully debugged and rewritten. The main problem has been to get the timing contrains of the SPI signals to be within requirement, so the interface code had to be rewritten to get it to work at 25MHz. Still, when one wants to read a block, it takes over twice the transfer time for the SD Card to respond.. E.g. when it takes 1/25M=40ns per bit, or 512*8*40=163us per block to transfer, it takes about 362us for the card to actually start sending that block(!) What a stupid way to make a memory card...

So its not going to be as fast as first indicated, but still quite fast:

A program load requires access to the root cluster which can span several blocks. I recon that if the file is in a sub directory, the position of that directory is known, so one accesses the directory cluster instead of the root cluster. Anyway, an almost empty card will only require the reading of one or two blocks which takes 525us per block. After finding the entry, it will take 8.4ms to load a 8KiB program or 16.8ms to load a 16KiB program.

All-in-all I guess this time usage is of more of theoretical interest since it will be too fast for anyone to notice. That is unless you have a really full SD Card with all the files in the root directory

Once I have implemented all functions, I will the the SuperVixen to look for "autoload.prg" on the root and load+execute that program if present. There will also be a settings file that can contain some preset values. Anyway, it means that you can get your favorite disk menu program (or whatever) to load at machine boot.

[Kakemoms]

Short update:
After alot of debugging and correcting my own errors as well as bugs in the original code, I am now able to load and display the directory on the sd card. I still have a few problems to solve, but all the fundamentals seems to work.

Edit: Spoiler:

Showing the 4 files currently on the card. All 8KiB ROM images with a two-byte start address at the beginning (hence 8194 bytes long). Later I will convert all files over 1023 bytes to show as KB.

Commands can be implemented in a number of ways.. but thats for later.