Banked RAM cart

[brain]

Yes, all of the stuff has to fit in an IO area, and preferably 1 of them (I can see folks wanting to use this cart alongside another than uses another IO bank, like VIC-MIDI or some other expansion IO cart. So, I don't think it's good to tie both 2kB IO areas up.

I think it's a futile attempt to operate two carts on the VIC-20 that both use the I/O area for registers. Even if the registers don't collide - the carts will very likely kick each other out of operation by kidnapping the KERNAL vectors or other resources.

You're going to cut down on a lot of use cases. No external video cart, no VIC-MIDI (or other RS232 on the expansion port) option, nothing like those. Even UltiMEM plays nice with a cart in the other IO bank (unless you map RAM/ROM there, but I digress.

and RAM. Do we hold RESET low and skip ROM, using the uC to load some data into RAM on boot and then release RESET, mapping that RAM into BLK5 to auto-start?

I think that's better done with a dedicated ROM (area), mapped in as necessary. A reset, regardless of what kind, should not tamper the RAM. There could be a soft-loaded cartridge in BLK5 RAM, which the user wants to start. See my previous post mentioning a 'soft' reset for this reason.

Again, not sure I understand part of this. Regardless of ROM or RAM at BLK5, one still needs a flag to disable mapping in code at BLK5 to wedge the KERNAL, in case the user wants to soft load a cart at BLK5. Yes, my idea of using 8kB of RAM for init would tamper with RAM (maybe the top 8kB of the RAM address space). But, not having ROM makes the cart cheaper and simpler (no need to support registers for ROM, no need to support re-programming it, no need to buy it or find a place on the PCB for it.

B&W video @ 15FPS is 4096*15 = ~60K/second. But, one has to assume the uC is fast enough to read, unroll, save, and perform RAM housekeeping to keep up, so one should not need more than 2kB of SRAM to handle the video case. So, it mainly falls to expansion RAM needs for other uses. Is 2MB enough?

For RAM banking, probably yes. See above.

With the loop unrolling a transfer rate of 100 KB/s should easily be possible, which gives 25 fps (assuming a 4 KB MINIGRAFIK bitmap as graphics mode). The uC also should prepare the next 'page' of code while the 6502 churns along the current transfer code, otherwise a lot of speed is lost with the 6502 waiting for the uC to build the next chunk of transfer code.

Having the uC prepare the next page of code while the VIC is accessing it is indeed the difficult part of this idea, in my opinion.

Jim

[Mike]

You're going to cut down on a lot of use cases. No external video cart, no VIC-MIDI (or other RS232 on the expansion port) option, nothing like those. Even UltiMEM plays nice with a cart in the other IO bank (unless you map RAM/ROM there, but I digress.

Your common 40/80 column card will very likely occupy the vectors of CHRIN and CHROUT to make the screen editor work. There's the resource clash, as the SD card drive will also need these two vectors for file I/O with PRINT#/INPUT# (respectively, their KERNAL call equivalents).

The next issue will be the autostart procedure and video card firmware itself. The SD card drive cartridge may well be able start its own driver or reset to soft-loaded cartridge images in BLK5, but the video cart will just super-impose its own idea of what has to be in BLK5 on the bus, leading to data bus contention.

If anything, adding extra features like an own 40/80 column display or further I/O capabilities in the direction of fast RS232 or MIDI would have to go on the new cartridge, with appropriate software support. In a *later* version - no use to start with feature creep of other, mostly unrelated things to fast file I/O.

Again, not sure I understand part of this. Regardless of ROM or RAM at BLK5, one still needs a flag to disable mapping in code at BLK5 to wedge the KERNAL, in case the user wants to soft load a cart at BLK5. Yes, my idea of using 8kB of RAM for init would tamper with RAM (maybe the top 8kB of the RAM address space). But, not having ROM makes the cart cheaper and simpler (no need to support registers for ROM, no need to support re-programming it, no need to buy it or find a place on the PCB for it.

At one point, you need some firmware to boot up the device drivers on the 6502 side. That could be a firmware (E)EPROM, or - as you wrote - some space at the end of the expansion RAM filled from a firmware file on the SD card. In the latter case, that'd better be quickly done before the KERNAL checks for the A0CBM signature.

Having the uC prepare the next page of code while the VIC is accessing it is indeed the difficult part of this idea, in my opinion.

Nobody said it'd be an easy job.

...

But as I wrote, there's only so much I can unload here as bag of ideas and concepts. Not even beer and pizza phase, so to speak. Before I would start writing a single line of code or pinning down any components for the hardware, I'd like a reply by TLovskog regarding this:

You see the bag of ideas/concepts I am unloading here in this thread. Now, *does* it in any way resemble what you got in your hands?

I could imagine to launch myself at a re-implementation of this fast SD card drive. But the perspective of having this attempt being turned into a waste of effort - in case you change your mind and actually release GCart 2011 - is what keeps me from actually starting it.

[brain]

Your common 40/80 column card will very likely occupy the vectors of CHRIN and CHROUT to make the screen editor work. There's the resource clash, as the SD card drive will also need these two vectors for file I/O with PRINT#/INPUT# (respectively, their KERNAL call equivalents).

I'm assuming the cart lives in a configurable expansion slot, where BLK5 can be disabled on the cart, but yes, the video cart is the most troublesome. Still, the other carts won't have these issues.

If anything, adding extra features like an own 40/80 column display or further I/O capabilities in the direction of fast RS232 or MIDI would have to go on the new cartridge, with appropiate software support. In a *later* version - no use to start with feature creep of other, mostly unrelated things to fast file I/O.

I think it's best to find a way for carts to co-exist. feature creep or not, it's not economically justifiable to try to put all the expansion options in a single cart.

At one point, you need some firmware to boot up the device drivers on the 6502 side. That could be a firmware (E)EPROM, or - as you wrote - some space at the end of the expansion RAM filled from a firmware file on the SD card. In the latter case, that'd better be quickly done before the KERNAL checks for the A0CBM signature.

Which is why I suggest holding reset low on hard reset, to allow the cart time to populate the BLK5 mapped RAM, if that solution is chosen. Not sure how soft reset would be done (If the cart can sense a soft reset, or there is a register to prep for a soft reset, that would help)

Nobody said it'd be an easy job.

My point was that I think it's best to handle the loading of the larger portions of the RAM first, with sideloading, and work on this unrolled code idea as part of a second iteration of the solution.

But as I wrote, there's only so much I can unload here as bag of ideas and concepts. Not even beer and pizza phase, so to speak. Before I would start writing a single line of code or pinning down any components for the hardware, I'd like a reply by TLovskog regarding this:

Since it's a key idea in his design, it does seem prudent to let him carry it to completion. Maybe he'll chime in soon.

JIm

[TLovskog]

Gents,

Your interest in the subject has really raised my energy levels for this project. So let's make it a 10 year anniversary and I will be done with it this year. At least Mk I.

My problem has always been deciding feature set. Once I have done the design, the layout, gotten the boards done and seen it working I immediately starts working on a cheaper or better or ... Probably due to the fact that in my consulting work as electronic engineer I always have to do good enough.

Anyway ... what would be a reasonable Mk I be and at what cost? Over the years I have iterated through a couple of ideas. Need to pick one.

• 1M static RAM, 2M or 64M dynamic RAM. Divided into a number of 8k BANKs

• SD card obviously and running at QSPI I guess.

• BoM Cost of 20 USD, 30 USD ok?

• Mechanics. Regular re-purposed cartridge or custom? My designs have always used a strange shape to have a high yield (= low cost) 2-up PCB panel. And also a custom cartridge.

• Ability to map RAM to RAM1-3, BLK1-3, BLK5 and IO range?

• RAM1-3 seen as one block? Simplifies design.

• Maybe RAM1-3, BLK1-3 and IO if RAM, as one 32k block. Is it only BLK5 that really needs to be able to change BANK?

• And as many banks as is possible with the amount of RAM.With a few allocated to the cartridge itself to hold its firmware.

• Each BLK/IO configurable as enabled and/or write protected. Is there any use of write protecting BLK1-3 and RAM1-3

• What about buttons? My idea has always been reset and a configuration/diskmanager menu. The configuration button temporarily switches in code at BLK5 and raises NMI.

• LEDs to display enabled Blocks? Also show write protected? Current design has one bi color LED for each BLK. As well as to SD card activity and WiFi activity

• And the unrolled-code-generator is a given. In some of the ideas I have used, sideloading comes for free. In some we need additional components to isolate the adress and databus.

• In Mk I we drop BLE and WiFi? Simplifies CE and FCC.

What else?

[Mike]

My thoughts about the feature list, and strictly my own opinion only:

• 2 MB SRAM. As I wrote in earlier posts, this derives from 256 8K blocks.
• SD card drive as laid out before, YES.
• Regards BoM cost - exotic parts of course drive high the cost. Lower number of components surely helps. See below.
• PCB design - no preference. If it fits a standard cartridge shell, fine.
• RAM 1..3, BLK 1..3, BLK 5 freely assignable to any of the 256 available 8K blocks. It should be possible to hide the registers, so I/O is fully usable as RAM as well. UltiMem got this working, so yours should, too.
• RAM1..3 and I/O2,3 should map to $0400..$0FFF and $1800..$1FFF of the respective 8K block. That simplifies address mapping and is also the way UltiMem implements it.
• Re: Is it only BLK5 that really needs to be able to change BANK? - *All* external RAM must be able to map to any of the 256 8K blocks! Cutting the feature set here throws your new card definitely behind UltiMem.
• Buttons: Two resets - one that doesn't change the registers/memory setup, and one which also resets the cartridge registers. Perhaps a third button that can be read by 3rd party software. IIRC, this is the setup also used by UltiMem.
• LEDs to show activated blocks not strictly necessary. Should be clear from memory manager on power-on/reset and (mostly) from start-up message (except BLK5 and 'hidden' RAM1..3, of course). Disk activity LED, yes. Wifi - see below.
• Unrolled code generator: again YES, as laid out before.
• BLE (Bluetooth Low Energy) and WiFi? Expendable for Mk I, IMO - there are other solutions like WiModem on the user port, which deliver that feature set, too. If it simplifies CE and FCC, go for it!

What else?

I have some ideas regarding the menu system, included games/applications and programmer support. Let me think over those for the next weekend.

[pixel]

I have some ideas regarding the menu system, included games/applications and programmer support. Let me think over those for the next weekend.

Ermh... I didn't exactly plan to make INGLE a one-man stunt. Now I'm really a gnat's cock away from dropping that insane plan to make a GUI every VIC coder can use. :/

EDIT: No, I'm not.

[Mike]

@pixel: PM sent

[MCes]

@ Mike
If SD card support is discardable (to compensate it a backupped battery RAM could be employed) a flexible and cheap solution could be developed.

Please: my google translator don't find "Unrolled code generator", could someone explain? thanks

[Mike]

If SD card support is discardable (to compensate it a backupped battery RAM could be employed) a flexible and cheap solution could be developed.

You are kidding, right? We're talking about a fast SD card drive as core feature and you suggest to discard it?

Please: my google translator don't find "Unrolled code generator", could someone explain? thanks

Unrolled code is a programming technique to improve code speed. It mostly eliminates the overhead incurred by the looping instructions by concatenating several copies of the loop body. See here: Wikipedia: Srotolamento del loop.

[MCes]

@Mike
Thanks for "unroll" explanations.
Yes, I was thinking on something different: out of target!

[TLovskog]

Thanks Mike!

• 2 MB SRAM. As I wrote in earlier posts, this derives from 256 8K blocks.

2Mb it is, makes a nice round byte for banking as you stated.

• SD card drive as laid out before, YES.

• Unrolled code generator: again YES, as laid out before.

Yes, These are given.

• Regards BoM cost - exotic parts of course drive high the cost. Lower number of components surely helps. See below.

Ordinary parts that are still active with no EOL present. Right now below 20 USD.

• PCB design - no preference. If it fits a standard cartridge shell, fine.

Ok. Then I will probably go for a slightly shorter cartridge for lower cost PCB, with 2-up. 3D printed plastics with STL files available, as well as source on OnShape.

• RAM 1..3, BLK 1..3, BLK 5 freely assignable to any of the 256 available 8K blocks. It should be possible to hide the registers, so I/O is fully usable as RAM as well. UltiMem got this working, so yours should, too.
• RAM1..3 and I/O2,3 should map to $0400..$0FFF and $1800..$1FFF of the respective 8K block. That simplifies address mapping and is also the way UltiMem implements it.
• Re: Is it only BLK5 that really needs to be able to change BANK? - *All* external RAM must be able to map to any of the 256 8K blocks! Cutting the feature set here throws your new card definitely behind UltiMem.

No point in doing something less capable. So individual assignable blocks with enable/disable and write protect for all.
Maybe also an idea to use the same register for identification as UltiMem. $9FF3 with 2 nibbles. Would make sense for application software.
Same goes for the ability to "go stealth", absolute feature.

• Buttons: Two resets - one that doesn't change the registers/memory setup, and one which also resets the cartridge registers. Perhaps a third button that can be read by 3rd party software. IIRC, this is the setup also used by UltiMem.
• LEDs to show activated blocks not strictly necessary. Should be clear from memory manager on power-on/reset and (mostly) from start-up message (except BLK5 and 'hidden' RAM1..3, of course). Disk activity LED, yes. Wifi - see below.

LEDs for disk access, power (system ok), and possible connectivity.
2 buttons. One for reset with short push resets the computer with everything intact regarding registers etc. Long push cold turkey reset. The other user definable and/or NMI triggering.

• BLE (Bluetooth Low Energy) and WiFi? Expendable for Mk I, IMO - there are other solutions like WiModem on the user port, which deliver that feature set, too. If it simplifies CE and FCC, go for it!

To avoid BLE/WiFi simplifies. Hmm. Lets have that as a stretch goal.

I have some ideas regarding the menu system, included games/applications and programmer support. Let me think over those for the next weekend.

Fabolous. My cup of tea is hardware and wireless.

[Mike]

I have some ideas regarding the menu system, included games/applications and programmer support. Let me think over those for the next weekend.

Fabolous. My cup of tea is hardware and wireless.

One thing that occured to me over the weekend, which the hardware shouldn't miss out is RTC support for the drive. We'd like new files be correctly time-stamped, no? Setting and reading the RTC by the computer should be made compatible with the CMD command set as documented with the SD2IEC firmware.

Do you think it is possible to produce a prototype of the SD card drive with flashable firmware but besides that only including a 'standard' +32K or +35K RAM expansion? *) After all, before the hardware is finalized it should be thoroughly tested how well the new mass storage system integrates and inter-operates with all the software already there. There are quite some traps to avoid - with the FE3 RAM Disk for example, I had a exchange with Kananga over e-mail and PM that easily spanned more than 50 messages for bug hunting and feature adjustments before we arrived at version 1.0.


*) I could arrange with just +32K RAM, as my VIC-20 has the +3K already built in.

[TLovskog]

Hi,

RTC is absolutely in the plans. With either a coincell battery or a supercap as source. There will also be some backup SRAM. That comes with the RTC for free.

Let me think about the stripped prototype.

[TLovskog]

Sorry, but I am closing down all my VIC 20 projects. I might take it up at one stage. It takes energy always have it the in back of my mind, but never time for it. After 9 years with a lot of prototypes, but few done to the end, that is it.

[pixel]

Sorry, but I am closing down all my VIC 20 projects. I might take it up at one stage. It takes energy always have it the in back of my mind, but never time for it. After 9 years with a lot of prototypes, but few done to the end, that is it.

Pfff. Compare that to how hard I mess up. In midst of one of the most horrible catastrophes mankind has to endure my chronic depression is fading away. But what you're saying sounds like you're getting a Corona-induced one. Was assuming that all those lock downs everywhere would cause a flurry of new and exciting releases around here but I probably underestimated how sensitive you Earthlings are to solitude.