My hardware project :: GCart 2011

[TLovskog]

Short update ...

Final schematic review of the GCart 2011 found 3 small errors, which needs to be fixed.

After I have fixed them, the first prototype boards can be ordered.

And thanks for all cheerful feedback.

[joshuadenmark]

Hello Thomas

Keep up the good work, I anxiously await the outcome of your efforts

This new cartridge is definitely the favorite in my collection of Vic-20. cartridges if it ever comes into my possession.

I'm glad there are people with your talents that have time and desire to produce new hardware to our dear retro machines.

I'm also glad you found the 3 errors before the prototype was ordered.

[TLovskog]

Hi,

A little update.

I have received a few mails/PM around how it is going.

Well, it has been rather slow lately, most due to the fact that it has been a bit to much at work.

Hopefully that will be cleared out this or next week and then it is production time.

In the mean time I have been working slightly on the software.

[joshuadenmark]

Hi Thomas

Thanks for the update, i am looking forward to see pictures of the prototype when ready.

[TLovskog]

Another short update ...

Moving slooooowly ... it is a bit more cumbersome to develop for these "limited resource devices" than you are used to. Or, to be correct, we have all been spoiled with gigabytes, GHz, source level debuggers, fantastic frameworks, high level languages and compilers, and all kind of probing hardware ...

Then again, it is actually much more fun.

The sad truth however, is that this is a hobby project and the attention it gets is a bit scarce. I have my full-time job and then I am starting a company with some friends.

That said. The boards are off for production last weekend. Since it is a few 10 pcs, they are rather large (mostly due to the rather large cartridge form factor) and I opted for a 4-layer stack-up it is a bit expensive. So to counter that I used an PCB pool company in China for the first 10 prototypes. I opted for 18 days manufacturing and then transport. That got it down to roughly 130 EUR, but it will take a rough month (worst case, being a pool PCB company, they can be much quicker it all depends on luck and that the data is ok first time)

So that was the excuse, sounds better than "I am 43 years old and getting slow and lacy ..."

I do have completed a few software related things.

# Toolchain has been set-up with compilers, assemblers, linkers, SVN hosting, and emulators. Also I have converted to the new Microchip MP LAB X. Xilinx stuff is also updated to latest and greatest.
# Since I am not having any flash, mapped into VIC address space, to boot from I am simulating that with the CPLD and the PIC. That seams to work. The 3.3V/5V level shifting also seams to work. The loader for the above is done.
# Some specifications on what to include, how to work with URL, and the like ...
# Some old software that I am reusing have been resurrected from various media including type-ins and stored as source.
# Previously I had MP3 chip working and other bits and pieces. That has also been polished and packed into this project.

Being a notorious time optimist I will stop giving and dates, but I am aiming at May 2012 ... because then I have to start working with our pool and garden again, and finish it for the summer 2012 ... or my family will sell my VIC 20s ...

[joshuadenmark]

Hi Thomas

Thanks again for your firmly update.

Go ahead and write me up for a cartridge, but do not panic, no stress in the retro world when it is ready it's ready. Remember Vic 20 slogan: The friendly computer.

"I am 43 years old and getting slow and lacy ..."

oh, hope it doesn't comes to all, as I have only approx. 14 days left to be active in. ... then I become 43

Good day to all.

[Mike]

Hi!

I am still quite intrigued how you are going to test the firmware.

The last bigger hardware projects featured in Denial, namely Mega-Cart and FE3, were by no means one-person efforts. There existed early prototypes of the hardware, which gave the firmware developers a tangible platform to test their ideas. That also allowed to iron out bugs or (perceived) deficiencies in the hardware.

I find it quite interesting, that your internal expansion aims to reproduce the main function of my VFLI mod - even when the hardware needs to be programmed differently. But the necessary code for this must really be thought out with rigor, it needs to be cycle exact. If it works, that would at least make your VIC-20 the second confirmed one able to display VFLI images.

The Mega-Cart development went for over two years, so that's something I wouldn't expect otherwise for your project - but regular updates (photos of the hardware, real screenshots, progress of the firmware) would be quite nice indeed.

Greetings,

Michael

[TLovskog]

Mike,

I am not sure what you mean with the testing of firmware. I guess you mean the software running on the actual VIC 20 for the cartridge, like kernel wedge for the sd disk, wifi, diskbrowser etc. I do not see this as a major undertaking, which might be totally naive. The firmware in the CPU for the actual cartridge which does the major work is more challenging. The FPGA firmware is quite trivial, and lends itself well for simulation.

At some time I suppose I will need some betatesters.

I will of course update whenever there is something new, with pictures and videos as it evolves.

Thanks for the interest.

[Mike]

I guess you mean the software running on the actual VIC 20 for the cartridge, [...] I do not see this as a major undertaking, which might be totally naive.

I wouldn't say naive, but at least you might underestimate the necessary effort.

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.

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).

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?

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?

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. SD2IEC devices are JiffyDOS 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?

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.

I'll keep an eye on your project, let's see what results.

[TLovskog]

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.

[Mike]

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.

I had a somewhat similar idea for FE3, extending the CBM BASIC to show 480K free at the start-up prompt. It would at least have involved extending most internal data-structures to 24-bit address pointers (bank + 16-bit address), variables then need 8 bytes instead of 7. The string garbage collection would need a significant speed up by the use of back-descriptors, like in BASIC 3.5 and above.

Same BASIC as above had a JIT compiler to pre calculate and create a table of GOTO/GOSUBS etc to speed up execution. [...] And even more truth ... it wasn't that great speedup ... But if you do not test, you never know.

Did you take a look at Waterloo BASIC? That's exactly what it does: the tokens of all new keywords are followed by a 16-bit address, the target, when the command diverts control flow. It has be thought out well enough so one can easily dispense with GOTO and GOSUB.

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

For the external memory blocks, you could have the external CPU inject the data from file at the right place without any assistance of the 6502.

But with the internal memory, you surely need the 6502 have to execute code like 'LDA #byte:STA target' / 'LDA source:STA I/O_register' in an unrolled loop with that code injection to simulate DMA?

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.

No worries.

[TLovskog]

Did you take a look at Waterloo BASIC? That's exactly what it does: the tokens of all new keywords are followed by a 16-bit address, the target, when the command diverts control flow. It has be thought out well enough so one can easily dispense with GOTO and GOSUB.

Will have a look at it, thanks for the note.

For the external memory blocks, you could have the external CPU inject the data from file at the right place without any assistance of the 6502.

But with the internal memory, you surely need the 6502 have to execute code like 'LDA #byte:STA target' / 'LDA source:STA I/O_register' in an unrolled loop with that code injection to simulate DMA?

Yes. In the beginning I had thought of having the CoProcessor directly write to the memory. However. The problem is as you note the internal Block 0. So, since I couldn't get that I opted for always going through the VIC, to have one way.

And the injection works just as you say. The VIC will tell the PIC/FPGA that it wants something loaded. The PIC/FPGA will inject the needed unrolled LDA/STA pairs until finished. To compress the data I have thought of doing ...

Code: Select all

LDX #$00
STX $xxxx
STX $yyyy
STX $zzzz
INX
STX $nnnn
STX $oooo
INX
STX $qqqq
...
RTS

For all needed databytes. Typically all $00 -$ff would be needed. And that would be the fastest you could ever load something to the VIC.

[Kananga]

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.

Switching all banks to all BLKs sounds great! If you added DMA for external RAM blocks too, it'd be programmers heaven!

Nice work!

[TLovskog]

A small update ...

I have not quit the project, but my search for the cheapest 4-layer boards was not a wise move. I opted for a shared, non-profit way forward. The great thing is that it is half price, the poor thing is that more than I seams to use it. Christmas coming up, it looks like my design will not make it until 2/1 2012. Many many weeks lost.

In the mean time I have written as much firmware as I can by simulating the hardware enviroment. However, I am thinking about doing a step between real hardware and no hardware and mock it up with your typical breadboard.

Sourcing of components seams to be moving forward. Only hickup is that Xilinx stopped producing the 5V version of the CPLD I am using in the internal 8k modification. The OLED display I found dirt cheap on e-bay.

[eslapion]

I remember somebody at the university telling me that the cheapest sources for 4 layer boards were in china.

Take a look at this place and tell me if they give you decent deals.

http://www.pcbcart.com/