Raspberry Pi Pico 6502 emulator

[dp11]

Yep that's broken, I'll fix it. Thanks for the report

[jfoucher]

Great, I’m curious to see how you’ll do it

[dp11]

I've committed a fix. I haven't managed to test it as I have broken my build else where.

[dp11]

Hoglet has kindly tested this and fixed a few issues. I have also fixed my build, but haven't tested it yet.

[jfoucher]

Right, that works perfectly now. Here is the output I get when running the 65C02 tests:

Code: Select all

Starting
test 16 after 5902630 ticks speed is 5.90 MHz
test 16 after 11801521 ticks speed is 5.90 MHz
test 16 after 17700656 ticks speed is 5.90 MHz
test 16 after 23599912 ticks speed is 5.90 MHz
test 16 after 29499068 ticks speed is 5.90 MHz
test 20 after 35443416 ticks speed is 5.94 MHz
test 20 after 41825207 ticks speed is 6.38 MHz
test 20 after 48206004 ticks speed is 6.38 MHz
test 21 after 54467708 ticks speed is 6.26 MHz
test 21 after 60528794 ticks speed is 6.06 MHz
**************************************************
Tests completed after 65644089 ticks and 10.84 s at an average speed of 6.05 MHz
**************************************************

Thank you both!

[ThisWayUp]

NICE!

[jfoucher]

After messing about with the ARM assembly code for quite a while, I gave up trying to use it for this purpose. I could not familiarize myself with ARM assembly quickly enough to not run out of patience. Interacting with outside code written in C was a particular difficulty. So I decided to just throw fake6502 in there, and the performance impact is significant, but not enough to put the idea in jeopardy.

VGA output works fine (using a modified scanvideo from pico-extras)
I have added input from a PS/2 keyboard which is really easy to make work on the Pico.

Now, BASIC works fine, even though there is stille work to do implementing more VIC and VIA registers (I did the minimum VIC emulation to get BASIC working, and the minimum VIA emulation to get the cursor to blink

I have also included a schematic, in case anybody wants to try and run the code on their Pico.

Finally, here is a hello world gif:

You can also watch the full video

If you like, the full code and the beginning of a hardware design is in the github repository

Edit: a uf2 file ready to upload to your pico is here: https://github.com/jfoucher/picovic/releases/tag/0.01

[BigEd]

(I wonder if Dave or Dominic could sketch an example of calling a C function from within the fast 65c02 model?)

[jfoucher]

BigEd wrote:

(I wonder if Dave or Dominic could sketch an example of calling a C function from within the fast 65c02 model?)

There were actually very helpful already, and I managed to call C functions from assembly (to read from and write to memory for example) but interrupts proved to be too much of a challenge for me...

Anyway, for the time being fake6502 is good enough but I'll probably revisit the assembly code at some point in the future.

Regarding next steps, I would like to implement LOAD and SAVE from an SPI SD card adapter. Are there any resources anyone would recommend for doing that? Commodore filesystem specifications would be nice, as well as the translation that the 1541 performs between the data stored on disk and what is sent to the VIC-20.
Thanks for any resources you can point me to.

[BigEd]

It's great progress anyway! (Sorry, can't help with the Commodore file formats questions)

[cjs]

jfoucher wrote:

Regarding next steps, I would like to implement LOAD and SAVE from an SPI SD card adapter. Are there any resources anyone would recommend for doing that? Commodore filesystem specifications would be nice, as well as the translation that the 1541 performs between the data stored on disk and what is sent to the VIC-20.

On CBM machines the DOS runs in the drive, which basically is a small server; the computer sends requests over a serial bus (for the VIC-20 and C64; it's a parallel bus for the PETs) along the lines of "open this file" or "send these data" and the drive replies. So the computer itself knows nothing about the filesystem or FDC.

I think that by far the fastest and easiest thing to do would be to implement the hardware for this bus and then plug that into an actual device such as an SD2IEC (or even a real Commodore drive). You'd need to emulate just some of the PIO functionality of a 6522 VIA and use that to run GPIO pins that eventually go out to a DIN-6 connector. If you get clever you don't even need full level translation between the 3.3V GPIO pins and the 5V bus because the bus uses pullups (the output pins only ever pull bus lines to ground).

[jfoucher]

cjs wrote:

I think that by far the fastest and easiest thing to do would be to implement the hardware for this bus and then plug that into an actual device such as an SD2IEC (or even a real Commodore drive). You'd need to emulate just some of the PIO functionality of a 6522 VIA and use that to run GPIO pins that eventually go out to a DIN-6 connector.

I hadn't thought of doing it that way, because I don't have an SD2IEC device, only an SPI adapter for SD cards, but it's actually a pretty good idea. I also think the sd2iec firmware should give me some inspiration if I was to go the SPI adapter way.

cjs wrote:

If you get clever you don't even need full level translation between the 3.3V GPIO pins and the 5V bus because the bus uses pullups (the output pins only ever pull bus lines to ground).

Good to know, but I already have a 74LVC4245 on the board for the PS/2 port with 6 free pins, so I might as well use it.

if you have any info about what the DOS on the disk drive does, that would be good to have. I find looking at a spec and implementing it is sometimes easier that looking at preexisting code and trying to adapt it.

[jfoucher]

Progress is slow but steady. I managed to read data from the SD card attached via SPI using this great library.

I had to modify it a bit because of DMA / IRQ conflicts with the code I am using for the VGA output.

Then, though a combination of this diskimage.c andthis format description I managed to parse a .d64 file that is present on the SD card and output (to serial) a directory listing like you would get when running

Code: Select all

LOAD "$",8

as well as raw file data.

I have started hooking directly into the kernal routines from the C code to load the data and put it in the accumulator. Basically the C code detects if the PC is at the start of a serial input routine, set the A register to a byte read from the .d64 image at the correct offset, and sets the PC to the end of the input routine. This seems to do ... something, although not the correct thing.

I'm still not sure whether the 1541 does any translation between what's on the disk and what is sent through the serial bus. If anyone has info on that point, it will be more than welcome. Otherwise I'll have to dig into the sd2iec firmware, which is pretty complex (because it seems to emulate many devices and handle various fast loaders).

[BigDumbDinosaur]

jfoucher wrote:

I'm still not sure whether the 1541 does any translation between what's on the disk and what is sent through the serial bus.

The data flow seen on the serial bus is what is read from/written to the disk. Of course, timing marks to delineate sectors are involved but that is strictly in the purview of the DOS. Sector size on all Commodore (CBM) floppy drives is 256 bytes, of which two bytes are used as pointers to indicate the next track and sector at which a file continues. Those pointers have a different meaning in the last sector of a file; the track number will be $00 and the sector number will be the number of bytes to be gotten from the final sector.

If using direct-access methods, i.e., the Ux: DOS commands, the entire sector is available for storage—bytes $00 and $01 in the sector have no special meaning.

The 1541 stores the disk metadata on track 18, which track was chosen because it is midway between the extremes of read/write head travel. Metadata consists of the disk's name and ID, block allocation map (BAM), which is an "inverted" bitmap¹, and the directory, which is a sequential file list with administrative information attached. A directory slot is 32 bytes in length, with the filename occupying 16 bytes—short filenames are padded with nulls. Attached to the filename is a type, e.g., PRG, SEQ, etc., a size value in sectors, a pointer to the first track and sector of the file, and some other information.

The one "complicated" data structure on CBM drives is the RELative file. A RELative file is a SEQuential file with metadata in the form of "side sectors" that makes it possible to address the file as an array of fixed-sized records. All CBM drives prior to the 1571 had problems with the correct operation of RELative files, which usually required the use of a record position command both before and after a write operation to assure the record was correctly written (I no longer recall the specific problem that was involved). The 1571, when operating in "native" mode, and the 1581 had properly-working RELative file code.

Back in the days when I did professional development on the C-128 using floppy storage, I mostly used direct-access, since it was significantly faster for record-oriented applications than use of RELative files (and didn't have any DOS bugs). However, doing so required drive-specific code, since the database engine had to know about the logical disk structure in order to avoid stepping on something important, such as the directory—different drive models stored the directory and BAM at different locations.

—————
¹The DOS indicates a sector is free by setting its corresponding bit in the BAM. The bit is cleared when the sector is allocated to a file, hence the "inverted bitmap" description. An inverted bitmap is less prone to problems such as crosslinked files, something that has always been a problem with Microsoft's FAT12 and FAT16 filesystems.

The CBM DOS VALIDATE command reconciles the BAM to file status, resulting in the correction of some errors, e.g., "poison" files, that could otherwise result in a disk being trashed.

[jfoucher]

Thanks for all the great info. Hopefully I can at least get load and save of prg files working