Obtainium Retro
Member
- Joined
- Mar 23, 2024
- Messages
- 22
This is gold! :D Thank you.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Gold Card work...
- Thread starter Obtainium Retro
- Start date
Obtainium Retro
Member
- Joined
- Mar 23, 2024
- Messages
- 22
Some small items of progress and some clarification today.
Clarification first. I'm not only building a 680X0-based PC. I'm starting by building a prototype expansion card for the Sinclair QL that offers at least CPU, RAM and flash, and the video subsystem in the first iteration. Once the community writes drivers for that, I will sent the people who contributed a second board that is the same, but also has the SuperIO on it. Once that has drivers, everything exists to run QDOS/SMSQ on the machine without any original QL parts. At THAT stage I'd be working on the ATX board. I think it is important to do it this way for a couple of reasons: firstly, the QL is my home community. I owe them something remarkable. At least Q40i/Q60 grade. And, for getting me here, the QL community deserves a payback that is a little more enthralling than what is currently available. People have the Q68 but still long for the Q40/Q60. Q60 was a wonderful place to be, and I think it is the peak of QL development, easily out-QLing the CST Thors.
Last night I got a Pentium cache RAM working on a 68EC030. 7.5nS SRAM of 128Kx36, so 512K of zero wait state overkill memory. The memory is so quick that I can copy its entire contents to another cache SRAM in between 68K accesses around 140x/second. It could be a wonderful target for some hidden DMA. I could move 4x long words (16 bytes) in half a clock. Amazing. The interest in these synchronous SRAMs is they're so specific and specialist there's simply no market for them. They're available and incredibly cheap.
I acquired a reel of 2500 clock buffers. The buffers are ICS9112BG as I maybe mentioned before. Datasheet here: https://www.mouser.com/datasheet/2/698/REN_9112_17_DST_20101122-1996920.pdf The fun part of this IC (and of having 2,500 of them) is that it has 9 buffered outputs. I can give each section that needs a clock its own isolated buffered clock. No circuit will degrade the clock of any other section. I have decided to give each expansion port its own channel of isolated clock based on advice and experience of @zigzagjoe and his many wrangles with clock quality issues on Mac SE/30 PDS cards. Keeping clock domains separate is critical to signal hygiene.
I have honed in on a final expansion bus layout that will address most use cases without putting a huge burden on lighter uses. It is effectively a buffered processor bus system, with each slot having both full access to the entire bus for flexibility. Each slot has a pre-decoded select signal that can be used for simplicity, or ignored. Cards can use space not used by neighboring cards.
M.2 SATA will likely appear at some point, I have a verified schematic that's proven working. M.2 SATA small cards are ridiculously cheap. The interface and new products will likely be around for some more years.
Clarification first. I'm not only building a 680X0-based PC. I'm starting by building a prototype expansion card for the Sinclair QL that offers at least CPU, RAM and flash, and the video subsystem in the first iteration. Once the community writes drivers for that, I will sent the people who contributed a second board that is the same, but also has the SuperIO on it. Once that has drivers, everything exists to run QDOS/SMSQ on the machine without any original QL parts. At THAT stage I'd be working on the ATX board. I think it is important to do it this way for a couple of reasons: firstly, the QL is my home community. I owe them something remarkable. At least Q40i/Q60 grade. And, for getting me here, the QL community deserves a payback that is a little more enthralling than what is currently available. People have the Q68 but still long for the Q40/Q60. Q60 was a wonderful place to be, and I think it is the peak of QL development, easily out-QLing the CST Thors.
Last night I got a Pentium cache RAM working on a 68EC030. 7.5nS SRAM of 128Kx36, so 512K of zero wait state overkill memory. The memory is so quick that I can copy its entire contents to another cache SRAM in between 68K accesses around 140x/second. It could be a wonderful target for some hidden DMA. I could move 4x long words (16 bytes) in half a clock. Amazing. The interest in these synchronous SRAMs is they're so specific and specialist there's simply no market for them. They're available and incredibly cheap.
I acquired a reel of 2500 clock buffers. The buffers are ICS9112BG as I maybe mentioned before. Datasheet here: https://www.mouser.com/datasheet/2/698/REN_9112_17_DST_20101122-1996920.pdf The fun part of this IC (and of having 2,500 of them) is that it has 9 buffered outputs. I can give each section that needs a clock its own isolated buffered clock. No circuit will degrade the clock of any other section. I have decided to give each expansion port its own channel of isolated clock based on advice and experience of @zigzagjoe and his many wrangles with clock quality issues on Mac SE/30 PDS cards. Keeping clock domains separate is critical to signal hygiene.
I have honed in on a final expansion bus layout that will address most use cases without putting a huge burden on lighter uses. It is effectively a buffered processor bus system, with each slot having both full access to the entire bus for flexibility. Each slot has a pre-decoded select signal that can be used for simplicity, or ignored. Cards can use space not used by neighboring cards.
M.2 SATA will likely appear at some point, I have a verified schematic that's proven working. M.2 SATA small cards are ridiculously cheap. The interface and new products will likely be around for some more years.
Obtainium Retro
Member
- Joined
- Mar 23, 2024
- Messages
- 22
I've been out of action for a few days. Now I'm catching up with work and opening all the packages that came while I was distracted. Lots of fun components. I received a reel of digital video ICs and protection circuitry for them. This makes it very easy to have digital video out from the video chip. I do think it is important to support a 'modern' connection method for basic IO like keyboards and monitors. TTL RGB required a special monitor or an expensive or blurry upscaling device. I'd prefer to handle that upscaling in the digital domain. With 1080 or any of the commonly supported resolutions modern TVs display and with progressive scan.... Modern TVs and monitors can display down to 24P without any flicker and this hugely unloads the video IC's pixel clock compared to 56 or 60Hz frame rates. A SVGA or XGA resolution in 24P has 40% the pixel rate. This allows an order of magnitude increase in color depth at any given resolution. The digital video IC also allows pixel doubling and tripling so eg: 1024x768 can be a parent resolution to 512x384, 512x256, etc. Almost any TV or monitor with an HDMI/DVI input should support VGA 640x480, SVGA 800x600, DVGA 960x640, XGA 1024x768, and their 90 degree rotated equivalents.
One of the cool things about such a flexible video chip is the ability to use odd resolutions when it suits. 160x120 in 65,536 colors? Done! 1024x1024 in monochrome or 16 colors? Done!
Two people have asked me now "why not just use an RP2040 for digital video?" The Rp2040 is very capable of outputting low color VGA or hicolor DVI. With the VGA option, beyond single RGB per pixel, the available GPIO isn't sufficient to support very high resolutions in a flat memory mapped model. The device would have to be accessed through a register port, which puts a lot of requirements on the video driver. It not only has to maintain a shadow bitmap anyway, but also has to registerize the content for transfer to the RP2040. For reads there is no penalty, but for writes this imposes a doubling of write time. This becomes really apparent when EG: setting a whole screen to one color.
I further explored using a transparent cache on the CPU to reduce penalty for memory accesses. It seems not realistic, and not that helpful.
I was also asked about putting the CPU on a daughter card, and maybe having more than one CPU slot. The person is, like me, a RiscPC owner. I think this would be a wonderful place to end up. I think for getting started it's better to have simpler design goals. I am definitely open to this later on, though. Especially if asymmetric multiprocessing can be implemented, eg: a 68060 and a DX2/66 or StrongARM or etc.
One of the cool things about such a flexible video chip is the ability to use odd resolutions when it suits. 160x120 in 65,536 colors? Done! 1024x1024 in monochrome or 16 colors? Done!
Two people have asked me now "why not just use an RP2040 for digital video?" The Rp2040 is very capable of outputting low color VGA or hicolor DVI. With the VGA option, beyond single RGB per pixel, the available GPIO isn't sufficient to support very high resolutions in a flat memory mapped model. The device would have to be accessed through a register port, which puts a lot of requirements on the video driver. It not only has to maintain a shadow bitmap anyway, but also has to registerize the content for transfer to the RP2040. For reads there is no penalty, but for writes this imposes a doubling of write time. This becomes really apparent when EG: setting a whole screen to one color.
I further explored using a transparent cache on the CPU to reduce penalty for memory accesses. It seems not realistic, and not that helpful.
I was also asked about putting the CPU on a daughter card, and maybe having more than one CPU slot. The person is, like me, a RiscPC owner. I think this would be a wonderful place to end up. I think for getting started it's better to have simpler design goals. I am definitely open to this later on, though. Especially if asymmetric multiprocessing can be implemented, eg: a 68060 and a DX2/66 or StrongARM or etc.
Right On the project now is continuing on.I've been out of action for a few days. Now I'm catching up with work and opening all the packages that came while I was distracted. Lots of fun components. I received a reel of digital video ICs and protection circuitry for them. This makes it very easy to have digital video out from the video chip. I do think it is important to support a 'modern' connection method for basic IO like keyboards and monitors. TTL RGB required a special monitor or an expensive or blurry upscaling device. I'd prefer to handle that upscaling in the digital domain. With 1080 or any of the commonly supported resolutions modern TVs display and with progressive scan.... Modern TVs and monitors can display down to 24P without any flicker and this hugely unloads the video IC's pixel clock compared to 56 or 60Hz frame rates. A SVGA or XGA resolution in 24P has 40% the pixel rate. This allows an order of magnitude increase in color depth at any given resolution. The digital video IC also allows pixel doubling and tripling so eg: 1024x768 can be a parent resolution to 512x384, 512x256, etc. Almost any TV or monitor with an HDMI/DVI input should support VGA 640x480, SVGA 800x600, DVGA 960x640, XGA 1024x768, and their 90 degree rotated equivalents.
One of the cool things about such a flexible video chip is the ability to use odd resolutions when it suits. 160x120 in 65,536 colors? Done! 1024x1024 in monochrome or 16 colors? Done!
Two people have asked me now "why not just use an RP2040 for digital video?" The Rp2040 is very capable of outputting low color VGA or hicolor DVI. With the VGA option, beyond single RGB per pixel, the available GPIO isn't sufficient to support very high resolutions in a flat memory mapped model. The device would have to be accessed through a register port, which puts a lot of requirements on the video driver. It not only has to maintain a shadow bitmap anyway, but also has to registerize the content for transfer to the RP2040. For reads there is no penalty, but for writes this imposes a doubling of write time. This becomes really apparent when EG: setting a whole screen to one color.
I further explored using a transparent cache on the CPU to reduce penalty for memory accesses. It seems not realistic, and not that helpful.
I was also asked about putting the CPU on a daughter card, and maybe having more than one CPU slot. The person is, like me, a RiscPC owner. I think this would be a wonderful place to end up. I think for getting started it's better to have simpler design goals. I am definitely open to this later on, though. Especially if asymmetric multiprocessing can be implemented, eg: a 68060 and a DX2/66 or StrongARM or etc.
Cool a RicsPC owner, but I unfortunately have none now.
Still deal with a lot of PowerPC chips and newer IBM Customs Made and designed microprocessors, but very little real ARM devices.
..
Any chance of a 512x512, 768x512, 768x786 modes, even if it is done in software emulation.
I hate to mention them but 512x384 was listed. Basically looking at a 12 to 16 color mode or greater.
..
So I thought I would throw this to you, as well.
I hate to mention them but 512x384 was listed. Basically looking at a 12 to 16 color mode or greater.
..
So I thought I would throw this to you, as well.
Obtainium Retro
Member
- Joined
- Mar 23, 2024
- Messages
- 22
The video system I created can have any arbitrary resolution from 160x120 to 1024x1024 in even numbers. It supports 1/2/4/8/15/16 bits per pixel, so 2/4/256/65536 colors. There is a CLUT so arbitrary colors can be associated with any internal value, which is quite flexible. As long as the pixel clock doesn't exceed 40MHz and you're using 8bpp or less so 2 pixels or more are read per memory cycle, giving an effective pixel clock of 80MHz. This allows, for example, 800x600@80fps.
So yes, you would be able to create any of these modes.
I would like to see a driver that could accept RiscOS-style monitor definition files. It is important to allow the video system to be configured to fit the nature of what is being displayed. EG: for vintage style gaming, lower bit depth/resolution, using the CLUTs, and minimizing the amount of data that needs to be transferred per frame gives the smoothest gameplay. For a web browser or mail client, a higher resolution and bit depth would help, but frame rate becomes much less important. With modern panels supporting 24/29.98/30/50/59.96/60 FPS and some panels supporting dynamic frame rates for gaming, anything is possible if the data can simply be presented in a compatible digital format.
So yes, you would be able to create any of these modes.
I would like to see a driver that could accept RiscOS-style monitor definition files. It is important to allow the video system to be configured to fit the nature of what is being displayed. EG: for vintage style gaming, lower bit depth/resolution, using the CLUTs, and minimizing the amount of data that needs to be transferred per frame gives the smoothest gameplay. For a web browser or mail client, a higher resolution and bit depth would help, but frame rate becomes much less important. With modern panels supporting 24/29.98/30/50/59.96/60 FPS and some panels supporting dynamic frame rates for gaming, anything is possible if the data can simply be presented in a compatible digital format.