Tetroid interfaces hardware info

Nagging hardware related question? Post here!
tetroid
Over Heated PSU
Posts: 142
Joined: Sun Dec 06, 2015 7:36 pm
Location: Novosibirsk, Russia

Re: Tetroid interfaces hardware info

Post by tetroid »

Thank you very much.
I will try to make it.


I still have my QL items still available, anyone interested, please contact me at tetroid@inbox.ru
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid interfaces hardware info

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tetroid
Over Heated PSU
Posts: 142
Joined: Sun Dec 06, 2015 7:36 pm
Location: Novosibirsk, Russia

Re: Tetroid interfaces hardware info

Post by tetroid »

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 original INGIT5 JEDEC.


I still have my QL items still available, anyone interested, please contact me at tetroid@inbox.ru
Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Tetroid interfaces hardware info

Post by Derek_Stewart »

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 copies of the JEDEC files for Super / Gold card and QXL.

I have supplied th to other hardware dedigners. I do not know if I have broken any copyright laws.


Regards,

Derek
Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Tetroid interfaces hardware info

Post by Nasta »

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).


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Tetroid interfaces hardware info

Post by RWAP »

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?


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Tetroid interfaces hardware info

Post by martyn_hill »

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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid interfaces hardware info

Post by tofro »

What's done in the QubIDE driver is the following:
  1. 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.
  2. 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"
  3. 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.
  4. After the first access to the driver, the name change is reverted back.
QDOS has the fixed boot order containing the devices "BOOT" and "mdv" - Nothing else. There's also no built-in function to retry booting from any other device in case those two fail. Any further chaining would have to be implemented in the drivers - apparently, it isn't.

(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
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Tetroid interfaces hardware info

Post by martyn_hill »

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...


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Tetroid interfaces hardware info

Post by RWAP »

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!


Post Reply