MrPix

If you assert 0 to FFFFh all subsequent accesses to the top page would be SRAM reads. If you assert 1, all accesses would be writes. The decoder and D0 working a flipflop that selects between read and write, through an AND gate where the other input is the PLL 3/4 timing signal so you know the data is stabilized. Then you can be sure it's a well timed data cycle latch and not a port cycle.

Let me rephrase that: A0..14 - direct A15 - OR the bank select lines D0..7 - direct For paging, if you use the Z80 IO area to get page selections, you can accurately capture the page intended regardless of read or write status because the value will always be set (write) or checked (read). Latching that will always give you the correct current page. Timing when data is valid is a fun one. For this you use a PLL to sync to the basic clock cycle, and multiply by four so you can accurately tell which cycle of any transfer you're in to latch data. The memory/port issue (and refresh) is solvable the same way. However, the CV and Adam have the expansion connector that solves all these problems

Well, if you decide to port to other platforms and want a new PCB for those... In which case there's much more fun and interesting ways to do it, since you have room to implement a full 16-bit address decoder. The CPLD/FPGA has access to all reads/writes across the entire memory map on the address and data buses. A few signals on the control bus aren't available, but can either be deduced or are irrelevant. Either way, it means you can do the paging from within unused areas of the Z80A IO area that happen to also be backward compatible with Adam internal RAM expansion. This means you don't have to leave any holes in one of your ROM pages, and can page all four pages in a CV/Adam with ROM or SRAM and give the SRAM read and write access without the read/write line. I'd be happy to PM you about this and some other ideas I have, where my hardware and your coding skills might overlap to make something deliciously compelling.

Yes. I just need to roll back some design elements I incorporated as the ADE developer doesn't want to implement them. Maybe 6 weeks? It'll be less than half the price of the existing releases. Right now, about $45-55? I've been slow enough that the other person has pretty much filled up the market, so I expect volume to be pretty low. I'll assemble 50 and see how it goes.

Oh, no, I encourage it. These ideas and suggestions lead to new open source hardware/add-ons! I've been working (mostly unsuccessfully) on porting CP/M 3 to the Adam and adding in support for bitmap graphics to use a full on video card. The potential is amazing... But, it requires me to play to a lot of my weaknesses, and not just my strong suit of PCB design. That came about because of an off-topic but still very interesting comment. Right now I am looking at the really quite underperforming SGM(1/2) and thinking how reasonable it might be to design and build an expansion cart for the CV to add a lot of Adam functionality, VGA high res deep color output, Adam ROMs/expansions, more RAM, etc. etc. It's just thinking though in part due to the current lay-off, and a drop off in my side business and a small "I really need a proper pick and place machine, desperately" issue - I do have enough orders already to completely pay for the machine but in the current business climate, nobody's going to lend me the money to get it even with good credit. :/ Anyone want to buy me this for Christmas?

I remember those systems back in the day. Suitable for some uses, but not really ideal in fast gameplay. One system I worked with on the BBC micro whited the top half of the screen, then lit quarters then 8ths, then did the same vertically, so it could get down to a 1/64th of the screen in typically 6 scans. .12 of a second. Another system that knew exactly where the raster was in drawing could do it in two frames. A poster above pointed out that you could use the video sync directly (with a counter) and I didn't consider this option to extract timing info. Unfortunately, on the CV a cart doesn't have access to those lines unless you pass the video through the cart externally - which I have never seen. Either way, it's an interesting discussion and deserves its own thread, but I think it's out of scope for a simple paged memory cart.

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.

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.

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?

The board would have RGB output. A second board I designed takes RGB input and converts it very cleanly to S-Video and composite, with really good dot crawl performance. So all three can be had together. Just a matter of reconstructing a few missing sync pulses. All my projects are open hardware, and I typically release the schematics right away, and the gerbers after 3 months, so I can sell through a run to recover the development cost.

The 9928 is a chip that would really benefit from some active cooling. About the biggest thing to help it is replacing the original DRAM private memory with a small, modern SRAM and bus demultiplexer.

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.

*blush*

A suggestion well taken. I plan to have the board fit in place of the 8915 and have a socket for the 8915, and would include a socket to put in its place if it needs desoldering.

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

Small update. I have enough pins free to offer quite deep color, which means I’ll be able to hit both the NTSC and PAL palettes very accurately, within the limitation that RGB has a slightly smaller gamut than YPbPr.

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

I already suggested raising the overall impedance of two of the dividers, and it's just a matter of seeing what maintains the balance without adding a hue. I personally like that the dividers and caps are right before the LMH1251, which is the highest power draw component and can easily sink twice the current it currently draws. I've gone to a lot of effort to make sure it has good thermal relief.

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.

I did some back of the envelope calculations and the current drop is 26-30mA with a 10K resistor, and negative effects start showing up around 25K. While the cost of adding the resistors is small (0.3 cents?) the reduction in heating is also small - about 1.5-2%. This is at the coolest end of the board, with a very well traced component that will draw and dissipate heat quickly. Well, maybe, but waaaay better to do that now than when they've been made already! I'm the same way! Yes, it brings a little, but I'm not sure it's worth the trade-offs. It's close though. Let's see what Falonn thinks when he wakes up

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.

I just modeled it. 150K before U3 would make the signal path very noise prone. It would emphasize any differences between channels in U3. It wouldn't add anything to signal quality. Right now it's working near its full spec range, which is ideal to optimize the S/N ratio. I can see what your thought is though and Falonn did a lot of work in that area of the circuit. I think you'll be very happy with the results. I'm thinking of redesigning my S-Video and composite board to attach to this to get a VERY clean composite and S-video output for those who want that. I might even be able to fit it on the same board... However, that would require different NTSC and PAL versions.

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

Super high values result in visible smearing that would be worse with 720 or 1080 signals - this design can work all the way up there without difficulty. We've designed the board with that in mind. There might be some resistor/capacitor value changes between U3 and U6, but we're going to be conservative. Better to waste 20mA than sacrifice signal quality even in edge use cases.