I don't want to get into conjecture. I'm trying to be more realistic about what's within my capabilities and the amount of free time Nasta has. I've made enough promises - it's time to ship some things. I'm not going to let feature creep hobble me any more.
Yes, we've talked about scan-tripling to get 512x256 as 1024x768 VGA compatible timing. However, that's not in this timescale.
IF it comes along later, would you rather it be a small clip-on daughterboard, or an expansion card with thru-con?
Issue 8 discussions...
Re: Issue 8 discussions...
Although I'm not sure VGA should be on Issue 8, as that would change the project scope, I'm still in favour of VGA over HDMI:stephen_usher wrote:Given that VGA is getting rare now you might as well go the whole hog and create an HDMI output. You could probably build a stripped down version of the OSSC, which is open source so all the circuit diagrams etc. are available, and incorporate that into a daughter board.
- VGA is far simpler to implement
- Lower requirements for the price and complexity of chips and PCBs used, easier to avoid difficult soldering
- The QL was used with 4:3 screens, and VGA flatscreens of that format are easier to find than HDMI flatscreens
- VGA flatscreens with native 1024x768 allow an ideal, sharp display of 512x256 - I have two such monitors and wouldn't want to miss this perfect solution
- There is an overwhelming supply of tiny VGA to HDMI converters, typical cost €8 - opposed to €162 for the OSSC
- VGA is still available as alternative input on many new monitors. Quick search on a mainstream PC online shop resulted in > 50 models
Re: Issue 8 discussions...
Exactly what I wanted to writePeter wrote: Although I'm not sure VGA should be on Issue 8, as that would change the project scope, I'm still in favour of VGA over HDMI:
- VGA is far simpler to implement
- Lower requirements for the price and complexity of chips and PCBs used, easier to avoid difficult soldering
- The QL was used with 4:3 screens, and VGA flatscreens of that format are easier to find than HDMI flatscreens
- VGA flatscreens with native 1024x768 allow an ideal, sharp display of 512x256 - I have two such monitors and wouldn't want to miss this perfect solution
- There is an overwhelming supply of tiny VGA to HDMI converters, typical cost €8 - opposed to €162 for the OSSC
- VGA is still available as alternative input on many new monitors. Quick search on a mainstream PC online shop resulted in > 50 models
It is also simpler to pass a VGA signal through the regular QL connector even though an adapter cable would be needed - but that's always needed, jsut with different end connectors anyway.
ISS8 is intended as a re-creation of the old motherboard, but without 'plugging up' some areas of advancement and tinkering. One problem present even if the particular user intends to keep the machine completely vintage is that we are running out of compatible CRTs. The youngest I have is now 22 years old!
Hence the idea to re-create a functional copy of the original graphics just capable of outputting VGA compatible timing.
That said, most users have a solution to view the normal 8301 output - for now. So the idea is to have the 8301 specific circuits (including 8301) on a small daughterboard that can be replaced by a VGA version when the time comes.
This is independent of anything else that could be added on the expansion connector.
Re: Issue 8 discussions...
Can an extra PCB be avoided when the 8301 is used? I'd prefer a single PCB mainboard.Nasta wrote:That said, most users have a solution to view the normal 8301 output - for now. So the idea is to have the 8301 specific circuits (including 8301) on a small daughterboard that can be replaced by a VGA version when the time comes.
Would the signals needed for future VGA be difficult to provide if a 8301 socket is directly on the mainboard?
Peter
Re: Issue 8 discussions...
Give us a few days to explore options and we might have an answer for that.
Give us a few more days after that and it might even be right
Give us a few more days after that and it might even be right
-
- Font of All Knowledge
- Posts: 3975
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Issue 8 discussions...
Hi,
I would like the best of both worlds, having the builtin video and have a video expansion socket so that a graphic card could be used.
This would future proof the board design.
I would like the best of both worlds, having the builtin video and have a video expansion socket so that a graphic card could be used.
This would future proof the board design.
Regards,
Derek
Derek
Re: Issue 8 discussions...
It would, but it might take us too far from the intent of an "improved, but not TOO improved, QL." It will probably be the revised 8301 system and a header block that has some jumpers on it to carry the video signals out and give access to all the SRAM pins. Later, the 8301 could be removed and a card pushed onto the pin block and into the socket, upgrading the output to nicely timed VGA.
I think using $36 of DP SRAM is really pushing it, but the benefits of that extra expense are absolutely worth the cost.
I think using $36 of DP SRAM is really pushing it, but the benefits of that extra expense are absolutely worth the cost.
Re: Issue 8 discussions...
Sooo. The rapid decision making has slowed, and we're looking at the semi-stable outline of a system now.
In essence, the main enhancement we're making is completely transparent to the CPU and OS, and that change that will give a good speed improvement. We've put the 8301 on its own private bus, isolated from the QL by 64K of dual port SRAM. This means the CPU never has to wait for video to be drawn, and it also separates the CPU clock from the 8301 clock.
We've decided that socketed 74-series logic, the socketing causes more problems than component failures do, so we'll be using SMD parts where possible. Maintenance/repair will not be much more difficult, and there are lots of people in the community who can do the work. However, I estimate it will reduce failures for those reasons by 50% or so - a worthy improvement.
The on-board RAM will also be fully static. I will use up my supply of 628512s, then move onto some other RAM that is pin and pad compatible. There will be an expansion header for RAM, which will support 12MB of DRAM - partly because it doesn't make sense to use 24x 512K SRAMs when 6x DRAMs will work, and partly because $15 of DRAM will work exactly the same as $60+ of SRAM.
Extension cards plugged into J1 will not be addressed when extended addresses the card is unaware of are accessed. Future boards will be extended bus aware and use a different connector.
So now we transition to the schematic design stage.
In essence, the main enhancement we're making is completely transparent to the CPU and OS, and that change that will give a good speed improvement. We've put the 8301 on its own private bus, isolated from the QL by 64K of dual port SRAM. This means the CPU never has to wait for video to be drawn, and it also separates the CPU clock from the 8301 clock.
We've decided that socketed 74-series logic, the socketing causes more problems than component failures do, so we'll be using SMD parts where possible. Maintenance/repair will not be much more difficult, and there are lots of people in the community who can do the work. However, I estimate it will reduce failures for those reasons by 50% or so - a worthy improvement.
The on-board RAM will also be fully static. I will use up my supply of 628512s, then move onto some other RAM that is pin and pad compatible. There will be an expansion header for RAM, which will support 12MB of DRAM - partly because it doesn't make sense to use 24x 512K SRAMs when 6x DRAMs will work, and partly because $15 of DRAM will work exactly the same as $60+ of SRAM.
Extension cards plugged into J1 will not be addressed when extended addresses the card is unaware of are accessed. Future boards will be extended bus aware and use a different connector.
So now we transition to the schematic design stage.
Re: Issue 8 discussions...
I'm sure you are aware this can easily cause flicker, and working out synchronization methods. Still my opinion as one of your hopeful cutomers: I have zero interest in speed improvements for this board! If keeping the clocks together can reduce work or risk, please do it.Dave wrote:This means the CPU never has to wait for video to be drawn, and it also separates the CPU clock from the 8301 clock.
Good. I can only second that from my own Qx0 and (S)GC experience.Dave wrote:We've decided that socketed 74-series logic, the socketing causes more problems than component failures do, so we'll be using SMD parts where possible.
RAM expansion header... megabytes... video expansion header... ROM expansion header... speed improvents... I know myself that such things are tempting. But my taste for this board remains: Better not here. I prefer this one as close to the original as possible.Dave wrote:There will be an expansion header for RAM, which will support 12MB of DRAM - [...]
Keep in mind that a really fast system would not benefit from all proposed expansions and optimizations. Whether it plugs into this board like SGC or replaces it - it would have it's own. Only saying because you want opinions. Always wishing best luck Issue 8 will ship!
Re: Issue 8 discussions...
Another thought: Will the sockets for the main QL ICs be at their original place?
For retro purism (the only reason why I want Issue 8) it would be important that traditional internal add-ons fit nicely. At least all Minverva and (Super)Hermes variants, QIMI, QL-SD.
Personally, I'd also like the 68008 socket available, was this planned?
I'd like to be able to re-use the original CPU for sentimental reasons. (Also I was using the CPU socket myself for a tinkered hardware add-on.)
For retro purism (the only reason why I want Issue 8) it would be important that traditional internal add-ons fit nicely. At least all Minverva and (Super)Hermes variants, QIMI, QL-SD.
Personally, I'd also like the 68008 socket available, was this planned?
I'd like to be able to re-use the original CPU for sentimental reasons. (Also I was using the CPU socket myself for a tinkered hardware add-on.)