MrPix

That said, you could use up to 24K of ROM and have 4K of RAM in the cart that is fully readable and writeable. That's a useful extra amount of RAM to have on a CV, if not on an Adam.

ftdi232, the low memory error is meaningless in this case. The memory is highly used, but the code's usage isn't going to cause it to run out. I'll leave the rest to Kalidomra, who is around and will be quick to help you.

At the end of the day, the switches fail. Some have the skill to refurbish them, some to replace them, and some neither skill.

If you unplug the IDE power supply, does the IDE drive work? Does the position of the drive affect the appearance of the noise?

I have two copies of that. One is fax monochrome so impossible to read half the nets. He other is grayscale, and ok far out, but you can’t zoom in much before it gets blurry. Worst thing is it has a few big errors. I’m working on corrections.

LO_IDEHA7_LeftSlot.pdf If you could extract the JEDEC from the GAL that would be.... Helpful?

For point two, visuals would help a lot. The sentence that really caught my eye was "ChildofCV's new schematics...." Are these of the Adam, or the CV? I'm currently capturing the Adam's top board for reproduction with modernization.

This is frustrating. The documentation out there said both ways. You have credibility, though. Rando documents on the internet - not so much. I haven't found an official Coleco document that describes the mechanism. I understand that the whole byte at 42h selects a 64K page to be addressed, subject to the configuration of the bottom nybble at 60h? Thus only 64K blocks can be paged, subject to the Adam's "master decoder" configured by 60h? If that's correct, extending this system will be much easier than I thought. Question: is it possible to disable the Z80A's interrupt/auto refresh function, if only SRAM or self-refresh DRAM were fitted?

*adjusts slightly* That's still only 16MB. My understanding was correct, but I was thinking in nybbles but drew bits - I guess I tripped my mind up by working out binary to find out the easiest sister address to decode in binary. The impact is still that there are 16 pages of 32K low and 16 pages of 32K high (because odd pages can only be low pages and even only high, which reduces the valid combinations /16.) This doesn't change the ability to support larger memory maps in a compatible way. It just means that 42h doesn't need to be shadowed. I'll consider the point further and revise the proposal.

A small errata, now it's too late to edit my post. With 42h, 1MB is addressable. With 42h/52h, accessed by 52h, 256MB is addressable. With 52h/53h, 4GB is addressable.

So I've hit a small snag with the Adam memory paging system, which in practice limits us to 1MB. The catch is that the Adam uses IO port 42h, but it only uses the bottom nybble (I spell it nybble, you can spell it nibble, let's co-exist!) which means 16x 32K pages lower 32K and 16x32K pages upper 32K. The upper nybble is ignored. Unfortunately, I cannot be sure that in all cases existing software will read/modify/write and not disrupt that upper nybble, so I cannot use it. What I CAN do is use a pair of other IO bytes to provide extended addressing. The lower of these bytes could be aliased to 42h. For example, if I chose 52h and 53h (which are available) and aliased 52h to 42h in my address decoder then I could do trickery like a write to 42h would also update the bottom nybble of 52h but not disrupt the top nybble by masking the top nybble. The consequence of this is that existing software, unaware of the the new scheme, would still operate correctly. New software or updated software, aware of the new scheme, would instead access 50h, with the top nybble also available. They would ALSO have access to 51h and two more nybble pairs. Thus: 42h: nnnn LLHH 52h: LLHH LLHH 53h: LLHH LLHH This is quite forward looking, because existing software has access to 1MB, and future software has access to 4GB of 32K upper and lower pages. If 53h is ignored, the pageable range from 52h alone is 16MB. I looked through the available IO space and selected 52h and 53h because in binary: 42h: 01000010 52h: 01010010 53h: 01010011 So this makes address decoding very compact and quick. 0000000010X001X is really easy to test for! So I am coming to the community to look at this and raise any unanticipated adverse events or conflicts that might arise. I propose this as a long term fix to a short term decision 38 years ago, that gives a programmer or use a choice to compatibly have a 1MB, 16MB or 4GB system, addressable in a backwards compatible and future-tolerant way. Discuss.

Instead of making this multi-card spread across multiple internal cards, I have decided to make it a single external board. This does of course mean more room so I might just add ADE to it for good measure!

Someone said my name? I'm working on a multicard that has as a memory component 4MB of DRAM or 2MB of SRAM. Up to 1MB, CP/M systems will use it as buffer space, and a few programs will use it as a RAMdisk, but nothing really *uses* that much. I am only including it because it costs the same to provide 64K or 2/4MB these days, and I have plans down the road which will make it very attractive. Also, with WiFi on the card, the ability to download much larger games than would fit in a single cartridge exists, so I am hoping it will form the basis of a new type of connected "megacart" to allow much larger game images in future. In theory, the Adam can support 16MB of RAM, through paging. I plan to implement a base of 2/4MB of RAM depending on system, and an 8MB expansion to give 10 or 12MB. 2MB will be free for future expansion, and 2MB for a new bitmapped VGA video subsystem, which is not 99x8 compatible, but far more flexible.

I figure the 3.58MHz clock is on a pin right there so I just need to figure out the relationship between it and the output. That would give me a per pixel clock, rather than a per line clock.

We all get our jollies in different ways

More on running a spinning platter HD on an Adam. The internal power supply has not got the spare oomph to run an older drive properly. It also probably won’t like a 7200 rpm drive. Really, there is no need to run one. A decent IDE to SATA or IDE to CF or SD adaptor will have you running solid state in no time. In my tests CF and SD are about 3x faster than IDE drives, and SSDs about 4.5x faster. This is mostly due to huge buffers larger than any file ever written by an Adam. If you’re determined to run a platter HD, you’ll need to run it off it’s own power supply, and you’ll have to bind that supply’s ground to the Adam’s ground. Usually, this can just be done with proper cabling. My IDE interface will be designed to not fit spinning platter drives without difficulty. I’ll use a 44 pin 2.5” drive header, which works with many SATA and SD adapters. Right now I am trying to figure out bus mastering and DMA. If that comes to nothing, it’ll still kick the pants off previous solutions.

I have had good with an SD card adapter on my first prototype IDE interface. It's 95% the same as the MI/MicroFox IF, so it should work on that too. Sd cards are the same speed as CF cards, much lower power, and a lot cheaper these days. I expect I will just include the SD adapter with every unit.

If I can access an in-time pixel clock (3.58MHz) then I would switch up to using a PSoC 5LP. It's soft of an FPGA, but not in the traditional sense. I have used one before to make a replacement video generator for the Sinclair QL, giving legal line doubled, pixel tripled output (to convert 256x256 to 768x512), and asking it to do something with 9928 video would be quite light work. However, I wouldn't go full on FPGA, as I simply don't have the skills or the attention span to completely re-implement the 99x8 family - especially because this work has already been done. Mostly, I just want to do something at a price point that it is accessible to a lot more people than traditional F18A prices. That rules out F18A-level development costs and time. I'll sit back and wait for your comparison. If you can screencap your scope, I'd be very interested in seeing the results.

Zinc paint. Buy a can. Next time your system is apart, mask off visible areas and spray the inside with the zinc paint. You will have no issues with lost sectors, TV interference or 737 Max’s crashing near your house ever again.

I tried getting two SD slot support added by the code developer, but they declined. Instead, I am going to create a generic ADAMnet backplane, and make sure the software can support two Adamnet devices side by side. The main need for the powered backplane is to create a powered hub for ADAMnet devices. Only about 500mA is available on the 5V supply, and the keyboard uses about 350-400mA. Or at least, on of my keyboards draws 355mA and one draws 397-8 mA. Part of this is the clunky old 6801, but the other element is loss from both rows and columns of the membrane being pulled up through 22K. 21 22K pull-ups add up. If I were to redesign the keyboard I'd use diodes on the wider side. If the 6801 were replaced by a modest Arduino, clocked slow, that 350-400mA could be reduced to maybe 120-150mA, leaving 350-380mA available for a couple of devices.

I’m going through the same process. What I’d really like is to relate the pixels to the pixel clock so I can digitize them and convert them to integer scaled HDMI. The problem is the delay of the conversion through the various versions of several mask revisions of 99x8/9 means the output has a lot of mixed relationships with the pixel clock from system to system. Any thoughts?

Yes, there’s a parallel port.

That's IT. Other Coleco trademarks have expired.

Specifically talking about the ColecoVision trademarks that are currently active, they are listed below. They're held by Colecovision Holdings LLC, a holding company that owns these marks, and may or may not own any Coleco IP. If they claim to hold any Coleco IP, they have to prove chain of ownership at every step. Here is the trademark on the ColecoVision logo in color: Word Mark COLECOVISION Goods and Services IC 009. US 021 023 026 036 038. G & S: video game cartridges and cassettes; downloadable video game software; computer game software for use with personal computers, home video game consoles used with televisions and arcade-based video game consoles. FIRST USE: 20131001. FIRST USE IN COMMERCE: 20131001 IC 028. US 022 023 038 050. G & S: Computer game consoles for use with an external display screen or monitor; Computer game joysticks; Game controllers for computer games; Hand held joy stick units for playing video games; Hand held units for playing electronic games; Hand held units for playing electronic games other than those adapted for use with an external display screen or monitor; Hand held units for playing video games other than those adapted for use with an external display screen or monitor; Hand-held games with liquid crystal displays; Hand-held units for playing electronic games for use with external display screen or monitor; Toy, namely, battery-powered computer game with LCD screen which features animation and sound effects; Video game consoles for use with an external display screen or monitor; Video game interactive hand held remote controls for playing electronic games; Video game machines for use with external display screen or monitor; Video game machines for use with televisions; Video output game machines for use with external display screen or monitor; Video output game machines for use with televisions. FIRST USE: 20131001. FIRST USE IN COMMERCE: 20131001 This is strictly a work mark in stylized form. The same logo without color is NOT covered. Description of Mark The colors black, red, orange, yellow, green and blue are claimed as a feature of the mark. The mark consists of the wording "COLECOVISION" in stylized letters with black outlines and with the colors red, orange, yellow, green and blue appearing in the letters as gradients. Separately, there is a mark for "ColecoVision Flashback": Word Mark COLECOVISION FLASHBACK Goods and Services IC 028. US 022 023 038 050. G & S: Computer game consoles for use with an external display screen or monitor; Computer game joysticks; Game controllers for computer games; Hand held joy stick units for playing video games; Hand held units for playing electronic games; Hand held units for playing electronic games other than those adapted for use with an external display screen or monitor; Hand held units for playing video games other than those adapted for use with an external display screen or monitor; Hand-held games with liquid crystal displays; Hand-held units for playing electronic games for use with external display screen or monitor; Toy, namely, battery-powered computer game with LCD screen which features animation and sound effects; Video game consoles for use with an external display screen or monitor; Video game interactive hand held remote controls for playing electronic games; Video game machines for use with external display screen or monitor; Video game machines for use with televisions; Video output game machines for use with external display screen or monitor; Video output game machines for use with televisions. FIRST USE: 20140920. FIRST USE IN COMMERCE: 20140920