No feature creep, it was hard to stick to it.

I did add a 3.8V LDO, internal 3.3V would be free but I like to get to 75% of 5V as high.

6x PLL from dotclock so will always be in phase for your cycle-counting 8bit c8051 code.

Every single expansion port pin is hocked up to a gpio.

Can fit seven 8KB carts images.
USB bootloader lets you swap in and out cart images.

Can also be programmed from the C64, as it will work as a 64KB REU,
but as it's flash, you should write-once-read-many.

Emulate a math-coprocessor as it does 12MHz multiplication
and 6MHz divisions (something that was available in 1980's)

Makes for a great dead-test cart.

No buttons, it checks nmi (restore key) so hit it twice within 1sec etc.
It then reads keyboard to see what other key you hold down.

You Tri-state in software, so some care is needed before/after MOVX.
In theory you could move data at 3MHz while Phi2 is high but C64's DRAM is 160ns, so 1MHz it is.

Only sticks out 12mm as usb is snug against c64 case



What pad goes to what pin AFTER i put the must be routed traces, could not be done on a 2layer board otherwise.


I ordered 4 boards ($7.50 each shipped) with digikey DK Red service, So Feb I will send carts to 3 top co-code helpers.

That's impressive.

This could start a whole new category of game development... games that use DMA without relying on the actual RAM expansion.

TomXP411 wrote:That's impressive.

This could start a whole new category of game development... games that use DMA without relying on the actual RAM expansion.

But that is a good feature of Sonic - loading the whole game to the REU memory.

Still, good to see new hardware.

Sonic using REU, a product that was available in 1980's, is cool.

Using my cart to emulate something that was available back then,
for a true retro vibe, but it can't emulate 256KB of DRAM.
Can emulate half of REU1700 if you would write ounce and read many as a function anyway

One reason it doesn't have 8KB of RAM and then use MAX mode
as you could then render everything at 48MHz with way more opcodes that a 6510, and only let the vic-ii show it, kind of cheating.

It does have 4K of RAM so you could do some half-height screens though.

I could use a RP2040 at 240MHz but did not, I use an 8bit 8051 for esthetics.

merman wrote:

TomXP411 wrote:That's impressive.

This could start a whole new category of game development... games that use DMA without relying on the actual RAM expansion.

But that is a good feature of Sonic - loading the whole game to the REU memory.

Sure it is, and I'm not dismissing that as a convenience feature. But not all games need an REU preload, and I'd argue that the DMA feature of the REU is more important than the RAM, when it comes to game development.

We can't do much about the price and availability of REUs, since the needed hardware does provide some constraints, but microcontrollers are both cheap and ubiquitous, and if we can put a microcontroller based DMA controller together for $40 or so, this is something pretty much every Commodore owner could afford, making it possible to develop even better looking games.

My cart should be able to emulate Commodore128 features.

Two 64KB banks, sure one is flash so only new games that knows this limitation.

2MHz 8502 as 8051 pretty much have the same opcodes, a direct translation is possible.

4MHz Z80A, very similar opcodes there too.

Its Advanced DMA feature is like the Amiga blitter, so new games can for sure be made to look better.

Or just use it as what half of a reu1700 could do, for true retro even for new games.

C8051 opcodes examples, like a 6510 plus a few more.
IAR (Sweden) have a C-compiler for it, 4KB code size for free.

TomXP411 wrote:That's impressive.
Sure it is, and I'm not dismissing that as a convenience feature. But not all games need an REU preload, and I'd argue that the DMA feature of the REU is more important than the RAM, when it comes to game development.

Yes. A much better way to provide the "no load" functionality is to add a bank switched flash ROM to the cartridge. So absolutely no problem that it is restricted to 64K, important is to make it simple enough that it becomes feasible to release a game on such a cartridge.

Yes, you can send commands to turn on 8KB (or 16KB) ROM images on the fly,
that are remapped to any address of the available 64KB flash, so you don't even need to dma, if this works for your game.
And this is retro-certified as there is nothing why this could not been done in 1980's (at least to even 8K blocks)

Could even set up a index table that micro-remap 256Byte blocks of data.
Call it: Extended $DF00 reu commands.

Maybe will add a TRRS socket for external interaction. (oh no, feature creep)
I have 0 gpio pin left, 1 gpio if use a usb-sense pin as general IRQ, do I have need to be able to pull nmi low?
a 2rd gpio skip powerdown pin for the pll (15mA)
a 3rd gpio if the EMI-read strobe can be turned off, or at least used as input-only.

Plan is to sell for ~$29 so 100's of C64 fans have the cart, so games will be created for it.

Hope to recoup R&D time so to get $15/hr after all said and done

tonyp12 wrote:so you don't even need to dma, if this works for your game.

I don't think that the VIC-II will be able to see the ROM, so bitmap scrolling still needs DMA ?

Ultimax-mode the vic-ii can see the upper external ROM bank
"On a trivia note, the UltiMax mode is the only mode where the video chip can access any external memory."

Then there is also this trick: A12 is pulled low by an external cartridge.
"This shows that a cartridge can hide any internal memory from the VIC-II and provide data for it on the Expansion Port.
Note that the internal color RAM is still read as usual."

tonyp12 wrote:Then there is also this trick: A12 is pulled low by an external cartridge.
"This shows that a cartridge can hide any internal memory from the VIC-II and provide data for it on the Expansion Port.
Note that the internal color RAM is still read as usual."

I don't think this works for a 128 in 64 mode, but I maybe wrong.

As the upper four lines are only held high with pullups, an external cartridge (like the Chameleon)
can pull them low. This is only allowed during VIC-II cycles. Certain combinations of the upper
addresses will disable memory and character ROM accesses, but only when GAME is driven low as
well (Ultimax mode). The VIC-II will then access ”open space”. Then the Chameleon is allowed
to drive the databus and feed the VIC-II directly. This makes it possible to completely change
the memory layout the VIC-II sees and is the trick behind the turbo CPU function.
Take note that the Commodore 128 behaves differently on
this point and is the main reason Chameleon is not compatible with this machine
(Maybe it's A15, A14 or A13 that needs to be pulled low unless table is showing buffer open drain state)

On the C128, there is an LS244 between A12 on the cartridge port and A12 on the PLA. Normally this LS244 drives A12 on the cartridge port, so you cannot pull A12 low. However, you can the reverse direction of this LS244 with the DMA line (because DMA is exactly made to allow cartridges to drive the bus) and then you can drive A12 and it will reach the PLA. The formula that makes the VIC-II access external memory does exist in the C128 PLA. Therefore it might be possible to modify the trick so it can work on the C128.

THE VIC-II is pulling AEC low at the same time anyway so pulling DMA low would not make any difference.

But DMA also pulls RDY pin low, so will 8502 have a hiccup if that happens?