Final Expansion 3 NG

[srowe]

As mentioned in another post I'm in the process of designing a refreshed version of the Final Expansion 3 cartridge and thought it may be interesting to others to record my progress here.

I'm planning to eventually produce (in limited quantities) complete carts, including case. I'm sure there's a demand for them and no one else seems to be building them at the moment.

Why not just build the existing rev11 design that e5frog put together a few years ago? A couple of reasons:

• I'd like to include the crosstalk fix
• I want to replace the full-sized SD card socket with a microSD
• I want to use more surface mount components

As I pointed out here, full-sized SD cards are getting harder to find. I'm mostly using microSD cards in an adapter but I've had reliability problems with cheap adapters.

Some of the DIP components on the rev11 design are harder to find, or more expensive than SMD footprints. SMD also means a more compact design which should make routing a bit easier.

I've decided to start from scratch, while I've used EaglePCB a little in the past this seems a good way of learning to use KiCad. I'm not a hardware engineer by profession but I've been building up some experience with smaller projects and thought this would be a fun thing to do.

I know there are members here who have many years of experience in this area, I'd like to hear if I drop an major clangers or if you have suggestions where I can improve things.

Next post will have the revised schematic.

[Wilson]

First of all, love the effort! I think the cross-talk issue stunted some of the excitement around this cartridge (at least it did for me) so it will be amazing to put that behind us.


One question. According to the manual:

RAM / ROM MODE (011zzzzz):
With Poke 39938,96 the RAM/ROM mode of the Final Expansion is enabled
...
The additional information in Register 1 (zzzzz) controls the selection of the VIC-20 Blocks.
Bit 4 controls BLK 5, Bit 3 Controls BLK 3, Bit 2 Controls BLK 2, Bit 1 Controls BLK 1 and Bit
0 Controls BLK 0. If the Bit is set to 0 then the RAM Block 0 can only be read not written.

It seems to me that the top bit of zzzzz is currently unused. Do you think it would be feasible to use a full 1 MB of RAM? As I understand the CPLD stuff was designed with some pretty strange tools, so I'd guess it's not super feasible if it requires much modification?

It would be nice if there was parity with the Ultimem in terms of RAM capacity. I'm speaking selfishly as I've been working on something very memory hungry, but there are several Ultimem only programs floating about that it would be cool to make available to a wider audience. And Pixel is actively working on one too it seems

[srowe]

First of all, love the effort! I think the cross-talk issue stunted some of the excitement around this cartridge (at least it did for me) so it will be amazing to put that behind us.

Thanks for the encouragement. I think the FE3 is a great cart, it rolls all the missing functionality (RAM expansion, storage) together and with the simple loader format allows quick startup of pretty much any game/application.

One question. According to the manual:

RAM / ROM MODE (011zzzzz):
With Poke 39938,96 the RAM/ROM mode of the Final Expansion is enabled
...
The additional information in Register 1 (zzzzz) controls the selection of the VIC-20 Blocks.
Bit 4 controls BLK 5, Bit 3 Controls BLK 3, Bit 2 Controls BLK 2, Bit 1 Controls BLK 1 and Bit
0 Controls BLK 0. If the Bit is set to 0 then the RAM Block 0 can only be read not written.

It seems to me that the top bit of zzzzz is currently unused. Do you think it would be feasible to use a full 1 MB of RAM?

I think my documentation of the modes in the User Guide explains these bits more clearly. They control which bank is accessed for RAM/BLK1/BLK2/BLK3/BLK5 but only one of two hardcoded banks. However, in Super RAM and Super ROM mode I believe there is currently a spare bit which means 1MB would be addressable (but only in those modes).

As I understand the CPLD stuff was designed with some pretty strange tools, so I'd guess it's not super feasible if it requires much modification?

I've virtually zero understanding of GAL/CPLD/FPGA programming, their toolchains are not "open" and I believe you have to use the chip vendor's programs.

It would be nice if there was parity with the Ultimem in terms of RAM capacity. I'm speaking selfishly as I've been working on something very memory hungry, but there are several Ultimem only programs floating about that it would be cool to make available to a wider audience. And Pixel is actively working on one too it seems

It would be great if someone like Diddl could confirm it but I think it would be possible to extend the memory range to 1MB. It just needs one more address line out of the CPLD and the firmware tweaking. The price of the larger SRAM looks to be identical to the current chip.

[Wilson]

Ah, sorry, I quoted the wrong part of the manual. Yes, "Super RAM Mode" would be the only relevant mode for the extra RAM.

It would be great if someone like Diddl could confirm it but I think it would be possible to extend the memory range to 1MB. It just needs one more address line out of the CPLD and the firmware tweaking. The price of the larger SRAM looks to be identical to the current chip.

Knowing nothing about the design, that's about what I figured. But if that still sounds reasonable after all the work you've done so far, that's a good sign!

Will be following closely!

[srowe]

It just needs one more address line out of the CPLD and the firmware tweaking. The price of the larger SRAM looks to be identical to the current chip.

In my enormously simplistic understanding of the CPLD code it needs A19 assigning to a spare pin

Code: Select all

pin 34 = A13;			/* EEPROM A13, SRAM A13 */
pin 38 = A14;			/* EEPROM A14, SRAM A14 */
pin 37 = A15;			/* EEPROM A15, SRAM A15 */
pin 41 = A16;			/* EEPROM A16, SRAM A16 */
pin 36 = A17;			/* EEPROM A17, SRAM A17 */
pin 39 = A18;			/* EEPROM A18, SRAM A18 */

then assign it from the latch (La4) here

Code: Select all

/* SRAM/EEPROM ADRESS BY LATCH */
A15		=  (La0 & _banking) # (_bank1);
A16		=  (La1 & _banking) # (_bank2);
A17		=  (La2 & _banking);
A18		=  (La3 & _banking);

[srowe]

Here's the completed schematic

I had to quickly dive into slightly more complex concepts such as creating new symbols as I couldn't find suitable ones for the microSD slot or the RTC chip. After an initial struggle I was able to make up just what I needed quite easily. I found drawing with KiCad less frustrating than EaglePCB and managing buses and wires seems more intuitive too.

I need to do a final cross check with the rev11 schematic, next phase will be the more challenging job of placing components on the PCB and routing the connections between them.

[mingle]

[*] I want to replace the full-sized SD card socket with a microSD

Oh please, no! I can (sort of) see the need for smaller-format cards for mobile phone, but for the FE3 a 'full-sized' SD card-slot is better.

It will also offer the option to use SD and micro SD cards. MicroSD are just too fiddly...

Mike.

[srowe]

Oh please, no! I can (sort of) see the need for smaller-format cards for mobile phone, but for the FE3 a 'full-sized' SD card-slot is better.

It will also offer the option to use SD and micro SD cards. MicroSD are just too fiddly...

Interesting you feel strongly about this. I'll have a check about what the long-term availability of full-size slots is. Perhaps I can support both footprints and make it a build-time option between them.

[MrSterlingBS]

Is it possible to install an IEEE extension that can access a second 6502 processor. Can be used almost like a FLoppy but of course without the mechanics and "only" equipped with RAM and ROM. RAM = 64kbyte; ROM 4kbyte?
According to my technical understanding, it should be possible. But, I don't have enough knowledge to build one myself.

BR
Sven

[mingle]

Oh please, no! I can (sort of) see the need for smaller-format cards for mobile phone, but for the FE3 a 'full-sized' SD card-slot is better.

It will also offer the option to use SD and micro SD cards. MicroSD are just too fiddly...

Interesting you feel strongly about this. I'll have a check about what the long-term availability of full-size slots is. Perhaps I can support both footprints and make it a build-time option between them.

Yeah, it's a bit of a bug-bear for me. IMO SD-cards were pretty much the perfect size for a whole range of applications, but technology is what it is.

Perhaps a poll would be a more democratic way of deciding which way to go?

Cheers,

Mike.

[srowe]

Is it possible to install an IEEE extension that can access a second 6502 processor. Can be used almost like a FLoppy but of course without the mechanics and "only" equipped with RAM and ROM. RAM = 64kbyte; ROM 4kbyte?

Sounds like your looking for an emulated storage serial bus device? I'm not sure why you'd want to use another 6502, unless you want to support block execute? Without some form of secondary storage (like an SD card) it would be of limited use, in my opinion. And with that you've basically implemented an SD2IEC again (only with more expensive components).

[srowe]

Yeah, it's a bit of a bug-bear for me. IMO SD-cards were pretty much the perfect size for a whole range of applications, but technology is what it is.

Perhaps a poll would be a more democratic way of deciding which way to go?

Full-size cards are easier to handle, I agree. I think I'll revert to that and experiment with an alternative footprint, they're still available at reasonable prices (which was one of my reasons for trying to replace them).

[Wilson]

FWIW, there do exist SD to micro-SD adapters. Granted, that does feel a bit sillier than the other way around
Out of curiosity, does anyone use a WiFi adapter or something to transfer files to/from their Vic? Or USB (does that even exist)? I'm not using anything more elaborate than SD card swapping myself, but it feels like maybe the real issue here is that whole process.

[srowe]

Out of curiosity, does anyone use a WiFi adapter or something to transfer files to/from their Vic? Or USB (does that even exist)? I'm not using anything more elaborate than SD card swapping myself, but it feels like maybe the real issue here is that whole process.

I'm guessing that FujiNet might be able to fill that role? I've not kept up with the progress of supporting Commodore systems.

[MrSterlingBS]

Is it possible to install an IEEE extension that can access a second 6502 processor. Can be used almost like a FLoppy but of course without the mechanics and "only" equipped with RAM and ROM. RAM = 64kbyte; ROM 4kbyte?

Sounds like your looking for an emulated storage serial bus device? I'm not sure why you'd want to use another 6502, unless you want to support block execute? Without some form of secondary storage (like an SD card) it would be of limited use, in my opinion. And with that you've basically implemented an SD2IEC again (only with more expensive components).

I would like to be able to do complete 3D calculations on the floppy. This of course includes some tables for multiplication, sine, etc. All necessary data should then be passed to the VIC, which draws the lines. This could perhaps be done in a slow screen clear routine and copy from memory to bitmap routine. The time for this would have to be around 80,000 cycles. Enough time to calculate 32 points?