Tetroid interfaces hardware info
Re: Tetroid interfaces hardware info
Thank you very much.
I will try to make it.
I will try to make it.
I still have my QL items still available, anyone interested, please contact me at tetroid@inbox.ru
Re: Tetroid interfaces hardware info
Just out of interest:
In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?
Thanks
Tobias
In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?
Thanks
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Tetroid interfaces hardware info
I have original INGIT5 JEDEC.tofro wrote:Just out of interest:
In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?
Thanks
Tobias
I still have my QL items still available, anyone interested, please contact me at tetroid@inbox.ru
-
- Font of All Knowledge
- Posts: 3972
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Tetroid interfaces hardware info
I have copies of the JEDEC files for Super / Gold card and QXL.tofro wrote:Just out of interest:
In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?
Thanks
Tobias
I have supplied th to other hardware dedigners. I do not know if I have broken any copyright laws.
Regards,
Derek
Derek
Re: Tetroid interfaces hardware info
It's a pity the original design equations are not available, as they could be re-targetted to a different CPLD.
It is possible to reverse-engineer the JEDEC but it is a truly tedious job assuming the jedec fuse map of the CPLD is available (and it's not a given that it is, some manufacturers never published this data).
The EP1810 is also a rather odd CPLD in that it is 'completely connected' and not organized in blocks interconnected with a crosspoint matrix like some other are, which sometimes makes it difficult to re-target the hardware (i.e. it may not fit into some comparably dense CPLDs), but since today much more complex CPLDs are available, not only should it be possible but also some features could be added (such as more RAM).
It is possible to reverse-engineer the JEDEC but it is a truly tedious job assuming the jedec fuse map of the CPLD is available (and it's not a given that it is, some manufacturers never published this data).
The EP1810 is also a rather odd CPLD in that it is 'completely connected' and not organized in blocks interconnected with a crosspoint matrix like some other are, which sometimes makes it difficult to re-target the hardware (i.e. it may not fit into some comparably dense CPLDs), but since today much more complex CPLDs are available, not only should it be possible but also some features could be added (such as more RAM).
-
- RWAP Master
- Posts: 2839
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Tetroid interfaces hardware info
I realised last night that there is a slight oddity with the Tetroid interface.
Bearing in mind its ROM is basically an amalamation of the QubIDE ROM and the Trump Card ROM, I would expect the boot order to work as win1_boot, flp1_boot and mdv1_boot
However, if win1_boot and flp1_boot do not exist, it does not check for mdv1_boot
Any suggestions as to why this might be?
Bearing in mind its ROM is basically an amalamation of the QubIDE ROM and the Trump Card ROM, I would expect the boot order to work as win1_boot, flp1_boot and mdv1_boot
However, if win1_boot and flp1_boot do not exist, it does not check for mdv1_boot
Any suggestions as to why this might be?
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
Re: Tetroid interfaces hardware info
Just to add that the same thing occurs with the SD Card interface - if no card can be mounted, mdv1_Boot isn't tried.
I think also that any 'virtual' device simply named 'BOOT' (i.e. without any device name in front) is enumerated during the standard QDOS boot procedure - before any physical device.
I'm not sure how other interfaces ever accommodated a fall-back to MDV, but I'm pretty sure that some did...
I too would be interesting to understand how to address this point.
I think also that any 'virtual' device simply named 'BOOT' (i.e. without any device name in front) is enumerated during the standard QDOS boot procedure - before any physical device.
I'm not sure how other interfaces ever accommodated a fall-back to MDV, but I'm pretty sure that some did...
I too would be interesting to understand how to address this point.
Re: Tetroid interfaces hardware info
What's done in the QubIDE driver is the following:
(I would BTW guess if you'd put an original QubIDE and an original Trump Card into a standard QL, the very same thing - i.e. not falling back to mdv when both HD and FD don't provide a file BOOT - would be happening)
Tobias
- The QubIDE driver installs a device named BOOT (that doesn't actually provide any files, but rather returns "not found" on any action). This is just to get the next step called at the proper time in the boot process.
- The BOOT device driver's "open" routine walks the list of device drivers and counts the number of device drivers named "mdv". This makes sure this is done after all device drivers are initialized, but before the system actually tries to open "mdv1_boot"
- In case the previous step says "1" (which indicates "no-one else wants to be the boot device replacing mdv" - Which also indicates the Trump card is using a different mechanism), QubIDE will temporarily re-name its own device (normally win1_) to mdv1_. This step makes QDOS "think" it booted from mdv1_, but instead it boots from HD.
- After the first access to the driver, the name change is reverted back.
(I would BTW guess if you'd put an original QubIDE and an original Trump Card into a standard QL, the very same thing - i.e. not falling back to mdv when both HD and FD don't provide a file BOOT - would be happening)
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 931
- Joined: Sat Oct 25, 2014 9:53 am
Re: Tetroid interfaces hardware info
Hi Tobias
That makes sense. It follows then that the ROM initialisation sequence itself is important - i.e. if an FLP or other device appears lower in the memory map and has already _USE'd mdv earlier in the ROM enumeration sequence, then QubIDE will take a back seat as far as boot order is concerned.
As you say, it is the responsibility of the driver code to carry out any 'chaining', if their own device fails to provide a Boot file. Interesting...
That makes sense. It follows then that the ROM initialisation sequence itself is important - i.e. if an FLP or other device appears lower in the memory map and has already _USE'd mdv earlier in the ROM enumeration sequence, then QubIDE will take a back seat as far as boot order is concerned.
As you say, it is the responsibility of the driver code to carry out any 'chaining', if their own device fails to provide a Boot file. Interesting...
-
- RWAP Master
- Posts: 2839
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Tetroid interfaces hardware info
It is indeed interesting - I must admit that when I had a QubIDE I no longer booted from microdrive so would not have noticed this behaviour.
I do however, seem to recall the Miracle HD disk chained properly with the Trump Card - ie win1_boot, flp1_boot, mdv1_boot, but then I might be mistaken - it was many years ago!
I do however, seem to recall the Miracle HD disk chained properly with the Trump Card - ie win1_boot, flp1_boot, mdv1_boot, but then I might be mistaken - it was many years ago!
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm