Calling homebrew writers: read this.

[MrPix]

Hey homebrewers.

I'm a hardware guy. I've designed a couple of options for improving the capacity of CV/Adam carts. I have a couple of options and would love to work with a couple of homebrew writers to release some much larger games with more advanced capabilities.

Option 1: 

Larger than 32K carts, using paging. 64, 128, 512K or more - a lot is possible. The extra could also be a mix of ROM and battery backed SRAM with an interesting write method and persistence of scores or play positions between games even after power cycling.

Option 2:

As above, but as a module with WiFi, to allow truly multiplayer games on different machines in different locations. This would allow all kinds of services like downloadable game libraries, team games, storing high score tables, leagues/seasons, games that auto update content over time, etc. etc. It does require a back end server, but there's so many little extras that become possible it could really expand your options over ordinary carts. Even just as a beta testing platform for private use, you can have it tell the beta tester a new version is available and 4 seconds later they're running it. This cart could also offer extended functionality for CP/M, BASIC programming, or etc. on the Adam. It would also add the option of PS/2 keyboards, bluetooth gamepads, etc. if someone else writes the drivers - I'm really a hardware guy.

Stretch goals:
More advanced sound, SGM-style functionality

If you're interested in basic concepts, we can chat here. If you're interested in co-developing something, PM me and we can sort out details.

Let's see what we can do!

MrPix

[jblenkle]

option 1 is already available.

[MrPix]

1 hour ago, jblenkle said:

option 1 is already available.

I'm aware of the megacart and the like. I'm talking about targeting something like that at a larger individual game - not just as a way of selecting multiple games or aggregate them on a single cart.

It's also significantly cheaper than the megacart, which is massively over-priced for what it is. A bit of competition never hurt anybody.

[Serguei2]

34 minutes ago, MrPix said:

I'm aware of the megacart and the like. I'm talking about targeting something like that at a larger individual game - not just as a way of selecting multiple games or aggregate them on a single cart.

It's also significantly cheaper than the megacart, which is massively over-priced for what it is. A bit of competition never hurt anybody.

Does your card work differently than megacard?

 

Do we need different tools to use with your card?

[MrPix]

I can make it compatible, or use a different/extended system to enable writes to SRAM in the ROM area. All depends on what the individual programmers want.

The way multicart/megacart works is "obvious" and "traditional" so it's not like I'd be infringing anyone's IP just for, you know, paging memory

That said, it's my preference to use space in the Z80's defined IO area than to use breaks in the ROM image as some systems do. The ROM cartridge sees accesses to the entire memory map, just not if they're reads or writes, and for ROM page accesses it doesn't matter if it's a read or a write. So the mechanism could be the same but the location could be different/patchable/definable to suit the needs of the programmer.  

[digress]

ready access to a 512KB or more pcb would be very welcome.

 

The atariage store has a https://atariage.com/store/index.php?l=product_detail&p=1045

it might be nice to have the option to save the vram/ram state and turn your system off + the voice synthesizer might be fun. 

 

I think a pointing device/mouse would be useful for point & click card games or general mouse related play.

It doesn't support a light gun hardware wise but maybe there might be a way for a crossbow or Cheyenne type game.

 

A way to blast video into the vram might be fun from an sd card. For like a driving/flying game.

 

colem can output to a midi sound using midi instruments. Maybe something like that that takes existing coleco sn76489 sound output and plays a synthesized version of each channel.

 

Hell for that matter. What about just triggering a digital playback sound device that sends full music or digital sound fx and simply combines it with the regular coleco sound output.

 

 

Edited May 28, 2020 by digress

[MrPix]

I don't know how I might save the state of the console's internal RAM unless I shadow it and make the cart an expansion card. Open to it, though.

It would be quite easy to add mouse support with memory mapped IO, so the X, Y position and button presses would appear in three bytes. I'd be up for it. The hardware to do this would implement a UART for MIDI in the same controller. 

I've only played with AY type sound devices, but I'm open to expanding my range.

Thanks for the ideas and suggestions. Much appreciated.  

 

 

[Serguei2]

1 hour ago, MrPix said:

I don't know how I might save the state of the console's internal RAM unless I shadow it and make the cart an expansion card. Open to it, though.

It would be quite easy to add mouse support with memory mapped IO, so the X, Y position and button presses would appear in three bytes. I'd be up for it. The hardware to do this would implement a UART for MIDI in the same controller. 

I've only played with AY type sound devices, but I'm open to expanding my range.

Thanks for the ideas and suggestions. Much appreciated.  

 

 

Speaking adding mouse, how about supporting two additional controllers.

 

It would be great to have games supporting 4 players.

[MrPix]

Adding controllers would be easier than adding a mouse. I just need to look at how the existing controllers are scanned or memory mapped...

[Tursi]

Aw, c'mon, what's with these puny memory sizes?

 

Let's port my Gigacart over to the Coleco.  

 

 

[MrPix]

Hehe. I can go big, but I don’t see individual games going that big. I have a 16 meg Adam RAM expansion just being finalized, but I got distracted by the 2MB bitmap based video card with hardware pointers.  

 

Don’t worry. Gigacart is on my list  

[Kiwi]

3 hours ago, Tursi said:

Aw, c'mon, what's with these puny memory sizes?

 

Let's port my Gigacart over to the Coleco.

Man, it'll be a big full Silver Red Moon moment with a big hint of a mania episode for me to fill an entire gigabyte of Colecovision game full of content. 

[Serguei2]

Another improvement I want to see on Colecovision.

 

Colecovision only has 16 colors to choose from.

 

How about using 16 colors from 64 colors or better. 

 

In IBM EGA, you can use 16 colors from 64 using Palette.

 

15 hours ago, MrPix said:

Adding controllers would be easier than adding a mouse. I just need to look at how the existing controllers are scanned or memory mapped...

I'm not a guy who wants to play on consoles using a mouse. 

 

Joysticks/gamepads/controllers are better suited for consoles.

 

For me, a mouse belongs to computers. But again, it's my opinion.

 

Hmm. I'm not sure if Adam supports a mouse.

[MrPix]

58 minutes ago, Serguei2 said:

Another improvement I want to see on Colecovision.

 

Colecovision only has 16 colors to choose from.

 

How about using 16 colors from 64 colors or better. 

 

In IBM EGA, you can use 16 colors from 64 using Palette.

I have designed a bitmap video card that supports a wide range of resolutions and can support deep color, but it would only work for new programs written to use it. I think a palette engine would be quite easy to do - the only hard part really is communicating to the palette what physical color each logical color represents.

 

[youki]

What i would love to have on the coleco , is a way to use a Light Gun.   Even better if there are a solutions that work with old CRT Screen  and new flat screen.   My next game will use that for sure. 

a mouse, would be interesting too, but i have the same feeling than Serguei2  that is more for computer.

[MrPix]

I've never personally seen a light gun for the 9928 VDP, because what the VDP is displaying is a free cycle independent of what's going on with the CPU and rest of the system. By the time the light gun sends a signal that triggers an interrupt that gets handled and the CPU queries the VDP a more or less random amount of time has passed. The CPU doesn't really know where in the display cycle the VDP is at any moment.

Is there a method for handling that?

[Serguei2]

24 minutes ago, youki said:

What i would love to have on the coleco , is a way to use a Light Gun.   Even better if there are a solutions that work with old CRT Screen  and new flat screen.   My next game will use that for sure. 

a mouse, would be interesting too, but i have the same feeling than Serguei2  that is more for computer.

Atari 2600, 7800, NES, Master System, Genesis and others support a light gun.

 

So why not on Colecovision.

[MrPix]

Because in all of these systems, the graphics system is monitor-able to where you know what is being output nS to nS. The 9928 is practically a separate computer that does its own thing with its own private RAM, and occasionally takes instructions and answers questions. The CPU doesn't know where the 9928 is in its drawing cycle - on all of those other systems, it does.

[ChildOfCv]

For a CRT-compatible light gun, you'd need a line counter between the CV and the TV.  It would also be the light gun plug.  On the good side, all it needs is the composite sync signal, so it would be possible to look at RGB, composite, or even component with almost the same hardware.  But it would still need a way to communicate its position value back to the CV.  That would either be a plug on the cartridge or an expansion port device.

 

For LCD and the like, well we still have the same old problems and the same jittery solutions.  But as much as the current solutions work, you could at least interface them to the CV with a little effort.

[Tursi]

On 5/29/2020 at 2:01 AM, Kiwi said:

Man, it'll be a big full Silver Red Moon moment with a big hint of a mania episode for me to fill an entire gigabyte of Colecovision game full of content. 

Ah, it's only a gigabit - 128MB.  I used it for Dragon's Lair, which took about 86MB.

 

If I had thought ahead when I did the run, I'd have designed it to dual purpose with the Coleco, but I was under duress when I did it. But I mean to test it on the hardware one day anyway.

 

[Kiwi]

5 minutes ago, Tursi said:

Ah, it's only a gigabit - 128MB.  I used it for Dragon's Lair, which took about 86MB.

 

If I had thought ahead when I did the run, I'd have designed it to dual purpose with the Coleco, but I was under duress when I did it. But I mean to test it on the hardware one day anyway.

 

That Dragon's Lair for the TI-99 was really awesome!!! 

[mr_me]

17 hours ago, Serguei2 said:

...

 

I'm not a guy who wants to play on consoles using a mouse. 

 

Joysticks/gamepads/controllers are better suited for consoles.

 

For me, a mouse belongs to computers. But again, it's my opinion.

 

Hmm. I'm not sure if Adam supports a mouse.

The colecovision roller controller already has the functionality of a mouse.  A mouse could use the same pinout.

Edited May 30, 2020 by mr_me

[digress]

3 hours ago, Tursi said:

Ah, it's only a gigabit - 128MB.  I used it for Dragon's Lair, which took about 86MB.

 

If I had thought ahead when I did the run, I'd have designed it to dual purpose with the Coleco, but I was under duress when I did it. But I mean to test it on the hardware one day anyway.

 

I assume that was using 8kb banks? 

 

128mb pretty cool.

[MrPix]

7 hours ago, Tursi said:

Ah, it's only a gigabit - 128MB.  I used it for Dragon's Lair, which took about 86MB.

 

If I had thought ahead when I did the run, I'd have designed it to dual purpose with the Coleco, but I was under duress when I did it. But I mean to test it on the hardware one day anyway.

 

If you'd like to share your paging scheme I could make mine 100% backwards compatible with yours, and then give you my extra functionality documentation. It would be good if different products had some kind of compatibility.

Also, if you'd like some help redesigning your board to be cleaner, I'd be happy to help. Just PM me. I really like how you hid the JTAG port behind the IC.

[+splendidnut]

18 hours ago, MrPix said:

Because in all of these systems, the graphics system is monitor-able to where you know what is being output nS to nS. The 9928 is practically a separate computer that does its own thing with its own private RAM, and occasionally takes instructions and answers questions. The CPU doesn't know where the 9928 is in its drawing cycle - on all of those other systems, it does.

That's not completely true... Example: The PPU inside of the NES is of similar architecture to the TMS9918 and derivatives (separate RAM, data, address buses) and has no built-in hardware light gun support.  Light gun processing is done mainly in software using different techniques.  One method of detection involves flashing a white filled box in each individual sprite location on a black screen.  Each sprite gets its own separate frame, so that the frame number in which light is detected corresponds to the sprite.  If light is detected, then that sprite is hit.

 

Works great on CRTs... but things like frame lag cause issues on LCDs.