Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Good

About MrPix

  • Rank
    Star Raider
  • Birthday January 11

Contact / Social Media

Profile Information

  • Gender
  • Location
    Austin, TX
  • Interests
    Retro hardware maker.

Recent Profile Visitors

858 profile views
  1. 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.
  2. LO_IDEHA7_LeftSlot.pdf If you could extract the JEDEC from the GAL that would be.... Helpful?
  3. 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.
  4. 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?
  5. *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.
  6. 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.
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. We all get our jollies in different ways
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...