Mike wrote:
The code for the CPU on your cart, and the FPGA firmware live in their own world, you can practically design them as you wish. But the software running on the VIC-20 which interfaces to your cart has to integrate well into the system and work with as many of the user programs as possible.
That is at least the aim. If it is something I really are picky about at work, it is people who do not go through published and governed API's ... unless there is a really really good reason.
Take the system level, file access: many programs expect a very similar behaviour to a CBM DOS floppy drive, especially when data is not only shown on screen, but processed further (say, a directory listing). Kernal messages like 'LOADING ...' should only appear in direct mode (that had been an issue with earlier FE3 firmware revisions).
A BASIC extension with turbotape I did back in the 80's did handle all I/O related stuff. LOAD, SAVE, OPEN, PRINT#, INPUT#, etc, so I have done it once atleast. Then again, with the internet it is on a MUCH higher scale. Back then perhaps 50 people used the stuff and it was tested on very few softwares.
System level, memory management: how are you going to expose the banking mechanism to programmers? The FE3 had one big design failure here: in Super-RAM mode, all 4 blocks are switched simultaneously, you cannot assign these freely to any 8K area in the 512K RAM. Which makes access to the extra RAM rather inconvenient, to say the least. The FE3 RAM-Disk, which is currently being developed by Kananga, is finally a good use for the extra RAM - 2 years after the FE3 had been released! Are you going to provide a 'transparent' mode, where your cart behaves just like a switchable memory expansion, nothing else?
All banks can be switched to any BLK[1-3,5] as well as 3k expansion. Plain memory expansion is possible with protected I/O-2/3 so programs that misbehave do not trigger any switching etc accidentally.
I have been thinking about beeing able to use the massive (relatively seen) amount of RAM for speeding up BASIC execution, in terms of how you store variable. The goal to reduce the searching for strings etc by the BASIC. It would need ~200 KRAM to have each variable stored at a location defined directly by the first to letters, even if the strings are at maximum 255 characters. However, arrays will mess that up a bit.
Same BASIC as above had a JIT compiler to pre calculate and create a table of GOTO/GOSUBS etc to speed up execution. In truth that was more a side effect that I added support for labels. I.e you could
ON A GOTO "START", "UPDATE", "GAME OVER", $TU. In the code you then had (anywhere)
Some Stuf": LABEL "UPDATE": Some more stuff
And even more truth ... it wasn't that great speedup ... But if you do not test, you never know.
Application level, disk management: well, there are already some other disk browsers around. They often work with a super-set of the CBM DOS commands, which once had been defined by CMD, and has also been adopted by the various SD2IEC devices. Is your disk browser going to use that expanded set (which allows, for example, to switch between disk images), and does your SD drive support that command set?
Now it is getting a bit trickier. There is a inherent compatibility issue with my approach. Since it is based on a parallel load directly from the SDcard (although through the CPU in the cart) and not emulation of the IEC serial interface. There is going to be pitfalls here. However, the intention is to be able to use my browser on the devices at hand, and other disk browsers should be able to use my SD card.
I intend to be able to switch between different disk images, tape images (if possible) as well as then online resources like
http://some-site/some-image.d64.
Then again I have not really read up on how the command sets work in detail.
In an earlier post in this thread you wrote:
So as long as the game/program uses the kernel routines it should work with multi-part. OR do these games use special tricks and/or routines?
There
are some floppy speeders around for the VIC-20, which load code into the drive and execute it there to speed up the protocol. The SD2IEC devices do not support this directly, unless they detect a known protocol by the code being sent (checksumming it), and then reimplement that protocol in code native to the controller.
Auch. That was a mess. Cool, but tricky to implement. No thought on that yet.
SD2IEC devices are Jiffy-DOS enabled, and there exists a softloadable version for the VIC-20, SJLOAD. How is the speed of your SD drive going to compare with SD2IEC/SJLOAD or the FE3 RAM-Disk?
This requires a much more finished product. However, the CPU on board and the SD interface will not be the limiting factor. It will be able to feed the VIC20 as fast as it can be received and stored in memory. The calculations so far (although a bit rough) would suggest a 8k block to be loaded in .1 - .2 seconds, then there are some overhead on setting that up, but less than 1 second. I have added some trickery in the FPGA hardware to be able to inject code into the VIC at running speed, which means that it could go down to 30-50ms for a 8k block (little depending on if we could compress the data.
I know, lots of questions, which IMO could only be adequately answered if either prototype hardware was available, or you had a complete emulation of both VIC-20 and your cart running.
Absolutely true. The above is the theory and the intention.
I'll keep an eye on your project, let's see what results.
Auch again. The idea with going public with projects is to have a little pressure to put some action to the words.
That said. This is a hobby project with a tight budget and very loose time plan.
