SuperCPU for the Vic-20

[Schlowski]

Looking great!

Later I will convert all files over 1023 bytes to show as KB.

Why? I really like to know the exact size (for whatever reasons, lol) and I don't think there is any reason to shorten the size onscreen. As far as I remember filenames can be 14 character max, right? Then we have 14 chars filename, a comma and max 5 digits for file size - that would be 20 chars, fitting nicely in one screen line.

But that's just nitpicking to shorten the waiting time

[Kakemoms]

Why? I really like to know the exact size (for whatever reasons, lol) and I don't think there is any reason to shorten the size onscreen. As far as I remember filenames can be 14 character max, right? Then we have 14 chars filename, a comma and max 5 digits for file size - that would be 20 chars, fitting nicely in one screen line.

But that's just nitpicking to shorten the waiting time

Oh, but FAT32 has long filenames which can be very long. So long as to become unreadable on the Vic-20 screen...

An option is to exclude the long naming convention and just limit it to 8+3 bytes (the normal FAT filename container). In that case, the file length in bytes can be shown (as it is now). I have tested it up to full 32-bit integer, so my code handles it ok, but for printing the full number, it becomes too large:

Code: Select all

FILENAME.PRG,4294967295BYTES

a shorted version without "bytes" do fit within 23 bytes:

Code: Select all

FILENAME.PRG 4294967295

Usually the files are much smaller, so we can add "b" or "bytes" after the file length in those cases:

Code: Select all

FILENAME.PRG 8192BYTES
or
FILENAME.PRG, 262144B

From your feedback I read that this last example is the preferred one?

[Schlowski]

Mmh, good point about the long filenames, we are on FAT(32), not on a CBM drive. Stupid me

For me 8.3 would be enough, but on the other hand maybe the others find it more conveniant to give their files longer and more expressive names.
As for the size, I don't see any reason for files to have sizes going into the mega or gigabytes.

If we just ignore the fact, that for very, very large files the display does not fit in one line, I don't think there is any necessity to append a B or BYTES or anything else.

So my solution would be

Code: Select all

MAINPROG.PRG, 23456
GAMEDATA.DAT, 524288
SAVEGAME.SAV, 512

[Kakemoms]

Had a hard time finding good specs about LFN coding in FAT32, but when looking at the raw data, the solution was obvious. So now it also decodes long filenames:

Just ignore the bytes in between as they are debug data.

[Kakemoms]

With bug fixes it now shows all entries and up to two lines of filename (39 bytes). Directories and Volume information is shown with separate endings (dir) or (vol) and it lists the number of files and directories at the last entries. If you want to see part of the listing, simply press run stop or space (which either results in break stop or pause).

[Kakemoms]

After a s...load of debugging I have finally made a source that can load programs from the SD card. Using sourcecode from another project was not the smartest way to do this, so I ended up remaking alot of it.

Anyway, here are some pictures:

Initializing a 8GiB SDcard takes 2-3 seconds. Smaller cards are faster. This is what the actual card requires to initialize memory and has nothing to do with the SPI interface or 6502-side software.

Displaying a rather large directory. RunStop works. Another SYS command to load a program. "POOL" did not start for some reason. Probably related to Basic pointers or something (will debug that).

Loading "The Pit.prg" instead. Loading of 10KiB takes a few milliseconds. It looks instant.

The Pit runs fine. Its a ok game.

The loading code will be moved to BLK5 and shifted to external SRAM when not in use. Loading to BLK5 will work (once implemented) so all games should load just fine. Protecting BLK5 is also not an issue (for cartridge games).

For startup I plan to put in an optional menu (it can be switched off if you like the plain Vic-20 startup message). Thus you can get the load commands as SYS (as shown above), LOAD"xxxx",6 or SDLOAD or whatever. There is generally no limit to how it can be implemented, so I will eventually add different options. SYS commands will point to IO2 which also acts as SPI buffer during loading.

All-in-all there are still a few bugs to get out, but with loading working I can start planning to mount the test units. I have also looked into doing a 50-pcs run of the unit. The reason is that it can be made fully assembled without insane overhead cost. Still, its risky to do assembly elsewhere, so I want to test the first 10 before doing that.

[Kakemoms]

I have been playing around with a menu (not finished) and a basic extension. Currently SD card commands have been finished:

SDIN (or SDINIT if you want to used the full name):

Commands have been tested to work in both immediate mode and as part of programs. Seems to be ok.

SDIR:

SDLOAD (or SDL for short):

With the current menu (which I will show you soon), the total code size is around 14KiB which fits nicely inside the flash memory of the MachXO3. I will keep you updated as things proceed.

[Schlowski]

Nice

[Kakemoms]

Hi

The menu/file browser is almost "finished" (e.g. alpha) and I am starting to plan for the final board production. With that in mind, I have some questions on preferences (to the users):

1) Do you want Hard Gold coated PCBs? This will increase the cost of each board by 30USD (at least for the first 10 test units)

The other option is ENIG gold coating which is much thinner and can wear off (if you plug/unplug the cart a lot). HASL (which has been used during testing) is not an option since it gives too poor contacts and wears down the Vic-20 gold pins (Gold actually reacts with the Tin --> not good). ENIG will work since there is a hard Nickel layer beneath the Gold, but it wears out more quickly.

2) Do you want a pre-filled SDCard? This only costs a few USD, but I can make sure that you get a card that works with the unit. Currently only SDHC cards work (I will probably add SD version 1 support later).

3) What is the most important part of a SuperVixen for you?:
A. Instant loading of files/games/utilities from SDCard
B. VGA output with clearer 22 column screens
C. Possibility of VGA output with a 40 column mode (not implemented yet)
D. A fast 25+ MHz 65C02 cpu as coprocessor
E. Expansion capabilities (25-pin port)
F. All of the above

Thanks!

PS: You can send the answers to me by PM.

[KilrPilr]

Hey Kakemoms,
Enig would be fine with me but if the majority of people want hard gold, then im good with that too!

Pre-filled SD card is cool and I would like that but its not necessary if it takes up a lot of your time. So long as the files are
available to dload, im sure most of us firsties can put it all together on our own sd cards and get it working.

and as for question 3, I love features so All of the above, F!

If we cant have it all, I guess my order of importance would be:
D,B,A,C,E

Hopefully that helps.

[Schlowski]

I'm totally with KilrPilr

[Kakemoms]

I have found a better supplier, so the additional cost is only 5USD per card for edge connector hard gold... meaning I will use hard gold for edge and ENIG (thin gold) for the rest.

Here are a couple of pictures of the menu system:

SDcard browser:

Still some bugs when testing on a real Vic-20. I guess the file format was slightly different IRL than under Vice.

Both pictures were grabbed from the CRT output.

[mingle]

Great stuff!

As per KilrPilr / Schlowski in terms of favoured options...

Cheers,

Mike.

[majikeyric]

Have replied with PM.

[Kakemoms]

Slightly less buggy:

You may notice that I use a 6-bit font. Its the original Vic-20 font that is compressed in realtime from the ROM. As for VGA output, it currently emulates the VIC output so that you get the same on the VGA screen and CRT.

There are a few possibilities for the VGA output. I plan to add a 40 column mode and some other stuff. The point of the 40 column mode should be to run some software that supports one of the other 40 column expansions out there. That is probably going to be a lot of work, so it won't happen too soon. I also want to make it accessible from the Vic-20 side which is possible due to the bus decoding. It means that the internal memory map can be used so that color memory and registers are going to be in the same place.

In the last days I have been looking into noise generation. There are a few small circuits that can be used, so I hope to include this.