MrPix

Like Apple. OS X is open source, but you're only allowed to run it on "Apple branded hardware"... Which is a fair proposition. Once CV has finished commercial activity with it, it might be nice to see it either licensed with a true open license or to issue a non-exclusive license to a couple of third parties so they can pick up the ball and run with it. My ambition would be to do an Altoids tin sized CV with it. But that's a separate discussion for another time and place. This is a KitBox expansion thread

If he's ok with me going for compatibility, it would be a good way to do it. I have a wireless one here that is quite nice if just a little bit small for my hands, and I'm just working through the details of porting the thing to fit natively on a CV. I've managed to reduce it to a very simple part that is under a dollar to do the interfacing if it's fixed remapping. I'll put it on the list and check in with him later.

I'll provisionally spec that, then, as I have a few samples here. I was thinking of black resist boards with a purple LED in a carbon black shell. The case would have some translucent sections in it that the power LED shines through. I could as easily add an RGB LED or two, but no existing game uses it and I suspect the main game publishers have no real desire to support it. It is moved up to the shortlist, though since you've suggested it. Good ideas. Keep 'em coming!

I was thinking more along the lines of it running a small webserver, and people could use the web browser on their phone/tablet to configure/update it? A lighter option might be a small OLED display and up/down/select, or a rotary/bush knob? I like dip switches just fine, but users have this terrible habit of throwing away the instructions No room because of the pizza oven

I haven't thought that far ahead yet. I'm not sure how the 6 buttons on mine relate to the Fire1/Fire 2 signals yet That said, it is a good thought that the buttons should be configurable easily to any keypad number desired.

It would plug into a regular screen if I did that. However, this is dependent on CollectorVision being willing to license or open source their core. That's quite a long way down the road from here.

The UART I chose has two ports. One is dedicated to the ESP32-D2WD processor (the chip off the ESP-32 wifi modules, but I'm using just the chip) and it has a variety of UARTs, and SPI/I2C support too. It would be quite easy to have that act as a large FIFO and implement what you ask. Are you more an FT232 or CH360 kinda guy? I hadn't thought about this, but a couple of neopixels might be fun? Would this be for the CV, Adam or both? It is on my blue sky list (BSL) to have Arduino capability on the Adam version. As an expansion on the Adam it can support 16 slices. There are four pins dedicated to slice position, so each expansion can be placed at any address on the expansion bus and this can be mapped to arbitrary locations in the memory map. I'm still noodling that out, because I might have a 16-bit Z80 in there with a flat memory map (boot time selectable). I think the CollectorVision Phoenix handles that role quite well. If they truly are doing this last run and that's it, I might seek to license the core for use in a miniature (Pi sized) console in the future - but we'll have to see how things shake out first. I really like the idea of a CV that fits in your pocket.

So, time for a fresh thread on the KitBox™, which is my expansion for the CV and Adam. It has SGM compatibility, and as a basic extra feature adds a headphone socket, volume knob and mixer knob. I'm looking to add a bit more functionality to it, and this thread is explicitly to ask for people's ideas of what else to add. Current ideas of features to add include: gamepad ports for Genesis/Atari/Amiga controllers a pause button possible audio out with mixer/volume control tone/EQ possibly serial/wifi for soft-loading games from the internet possibly SD slot for soft loading/saving games from/to SD There will also be an Adam-only version, the BigKitBox™, which will add features the Adam can use: all the features of the KitBox, plus expansion space to add expandable paged memory in 2MB increments - up to 12MB a 2MB bitmap video card, VGA output (see below) serial port parallel port IDE port (with CF and SD support) PS/2 (or maybe USB) mouse port WiFi MIDI speech The Adam BigKitBox might also add support for and include a ROM with CP/M 3, and a faster Z80A CPU for programmers. The BigKitBox was originally designed as an "MIB4 card" but unfortunately the combination of features I had in mind would not fit within any one Adam expansion slot. Both of these expansions will be based off the same base PCB, so in the future all the Adam options could be added to the CV if there were software support written by third parties. The video card is one of my most exciting additions. It is a bitmap video card that can support any arbitrary resolution from 160x120 up to 1024x1024, in 1, 2, 4, 8 and 16 bits per pixel, up to a limit of a 50MHz pixel clock. It is a bitmap video card, so screen contents are not produced in the same way as with a VDP but are a literal version of the bitmaps placed there. The card also has powerful palette capabilities supporting hi color screen modes, eg: 256 from 4,096 colors, 16 colors, or plain monochrome (which is very, VERY fast). It also includes hardware pointer support (so you can create multiple pointers of four colors (one is mask) selected from a private palette, and move them simply with instructions that in pseudo code are "place pointer at X,Y" - again, super quick and makes handling pixel data much easier. Finally, it has a FIFO so while it is a memory mapped device, the CPU is never kept waiting and can buffer writes or read requests to the video device. My intention is to include a CP/M port with drivers configured to use the display. The display can display 80x25 characters with ease, and can support today's wide screen monitors. The spirit of this thread is very much "moving forward." I'm looking for solid ideas of features to implement in a first generation new expansion - especially for the CV, with the notion that a second generation expansion with more improvements would arrive within a year. I have heard the very strong feedback of the other thread and it has not gone unheard. While I will retain SGM-compatibility the device will be a quite divergent product and the foundation of something much bigger. I appreciate some people may still want to take issue with what I'm working on. Please do so in PMs or a different thread as this thread isn't intended for that, but to be a positive and constructive CV and Adam hardware development thread. Everyone's time and patience is much appreciated. KitBox™ and BigKitBox™ are trademarks of 68K Computer LLC.

ChildOfCv, thank you. You're giving me so many pointers that act as huge shortcuts. They will save me a lot of time working things out and searching for reference materials.

And I'm only a few days away from receiving the last of the components needed.

Hmmmm. Looking at my NTSC book, it might be better just to have a preprogrammed playback of the entire blanking period, and insert that when you count out the last frame or half frame - based off the first frame being the first to have a color burst after it. That reduces it to just counting 262 sync pulses from the first burst after the blanking period, play back the new blanking period, then cut back in to the STIC's control and reset the counter. The only wrinkle is the odd/even fields with the half/whole and whole/half first/last scan lines. An incentive to do it this way is that it enables easier conversion to Pi Zero conversion for version 2. I'll poke at it on Mon/Tues and see what falls out.

I found a nice half hour read of the subject. It fills in all the blanks. Yeah, guy is trying to claim rights to things that don't directly link to him, plainly, and I learned a new concept of "passing off" that's made me rethink some past assumptions. I'm happy to act as a vehicle to oppose his TM filed status if anyone has any ideas.

They might be using it as a lever to initiate action for reverse passing off, as a wedge action to initiate a USPTO review of the TM.

Well, huh. It's education all round this evening I'll ask my business law attorney before I comment my nonsensical opinions in future.

Nope. That said, I've gone and informed myself since first commenting, and this Cardillo guy seems to be trying to adopt an expired trademark, and doing it ALL WRONG. Like, messed it up at every single opportunity.

I know nothing of this Cardillo. Is there a short summary of the shenanigans somewhere? I've googled but the results were noisy.

That's right, but that doesn't affect their right to sell what they have bought. As long as they do not misappropriate the firmware by claiming ownership of it (they might be able to claim it was a derivative work but that would be a long and very uphill battle for them somewhat akin to IBM vs. Phoenix). They can change the label on the box, and resell it under first sale doctrine. They cannot change copyright or TM notices, but they can remove a TM name and replace it with their own. It's a complex area, but First Sale Doctrine negates many TM protections. You can't infringe simply buy buying a legitimate product and then reselling it with a different sticker on it. If you counterfeit the trademark, that's a separate issue.

It's not that simple. First sale doctrine applies. Once Coleco has bought the items they're free to do as they wish with them. For CollectorVision, this is also a smart move. Coleco can't turn around and claim CollectorVision is selling the console without Coleco's authorization. This seems to be that sweet spot where by simply acknowledging each other's rights, both gain protections. I con't know anything about Coleco Holdings' claims to the property rights, but they're owned by Dormitus Brands. That company's claims may be legitimate - they're certainly high profile and this is their business model.

I think it was the HSYNC pulses itself. Sorry, my mind's been on other stuff the past few days (you were there) so I didn't remember it as clearly as I should. I'll give a definitive answer from the scope and logic analyzer on Mon/Tues. That said, I'm leaning towards the counter/framebuffer HDMI solution now anyway as the full fix, as that would cost 1/3rd what an OSSC does and give much more satisfying results.

Sweet deal! I'm glad you got this working. Sorry for standing on the sidelines and being able to offer any input. If all I have is guesses, I'm not adding anything.

I've set aside Monday/Tuesday to do some more work on this, and I'll grab some screen caps from my oscilloscope and logic analyzer and share them. That way I'll be able to give really specific timings and omissions. From casual observing it looks like the four HSYNC pulses before and four after the VSYNC. All during the blank lines.

Wonka is short for Wonkarico. Now it all makes sense!

Hehe, like I said, that's not my strong area The OSSC problem "seems to be" the sample/sync IC loses sync, so the OSSC falls down before any firmware element is in play. It's technically easier to regenerate the sync fed to the OSSC than to modify the OSSC firmware to interpret the nonsense the sync IC is giving. Then again, I'm not an OSSC expert. I looked at the schematic and went "oh, they used that not great but not really terrible IC, eh?" That's the limit of my exploration from that side. What I'll likely do is a quick and easy "doesn't work with OSSC" RGB, and then in a couple of months evolve that to fix the sync signals, and take the feedback from the plain Jane version to modify the colors a little. I have had the idea of using a counter alongside the sync pulses, and using this to create a virtual CPU bus to feed data into a Pi Zero to create low cost HDMI output. Catch is, while that would be a wonderful, simple and quite economical product, it would need someone to modify one of the open bare metal framebuffer packages out there so there's a nice pre-configured upscaling/line tripling, frame doubling option out there. That would be very satisfying, if anyone wants to do the ARM side of it.

I did some work on this yesterday, and made some progress. Enough to define what the sync problem is, and two possible solutions to bypass/fix it. It seems the most likely assured success will be by using a small microcontroller to count and average the sync pulses, and if one doesn't turn up within 2-3 clocks pf the expected sync, to generate it. This would be 2 or 3 cycles late at 16MHz, so still within the same clock cycle at 3.5MHz. This should be enough to get OSSC to maintain synch in the dead period. This has the advantage that it would work automatically with NTSC, PAL and SECAM. The other method is simpler and would use a counter and preset value all within the CPLD. This, however, would require specific testing and calibration for each system. What it saves in design complexity and build cost it takes back in lack of resiliency. The third option is to alter the ROM slightly so the correct sync signals are generated in the first place - but this would require having varying ROMs in different INTYs, and some people might not be happy with that. It's also not in my core skills area. What do people think?

Engineering and art in perfect harmony.