Tetroid interfaces hardware info

Nagging hardware related question? Post here!
tetroid
Chuggy Microdrive
Posts: 57
Joined: Sun Dec 06, 2015 7:36 pm
Location: Novosibirsk, Russia

Re: Tetroid interfaces hardware info

Postby tetroid » Mon Sep 04, 2017 8:44 pm

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


User avatar
tofro
QL Wafer Drive
Posts: 1154
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid interfaces hardware info

Postby tofro » Wed Sep 06, 2017 5:28 pm

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


tetroid
Chuggy Microdrive
Posts: 57
Joined: Sun Dec 06, 2015 7:36 pm
Location: Novosibirsk, Russia

Re: Tetroid interfaces hardware info

Postby tetroid » Thu Sep 07, 2017 6:57 am

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.


User avatar
Derek_Stewart
Aurora
Posts: 771
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Tetroid interfaces hardware info

Postby Derek_Stewart » Thu Sep 07, 2017 11:25 am

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
Trump Card
Posts: 189
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Tetroid interfaces hardware info

Postby Nasta » Thu Sep 07, 2017 1:42 pm

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: 2244
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Tetroid interfaces hardware info

Postby RWAP » Sat Sep 23, 2017 9:29 am

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
Trump Card
Posts: 230
Joined: Sat Oct 25, 2014 9:53 am

Re: Tetroid interfaces hardware info

Postby martyn_hill » Sat Sep 23, 2017 10:09 am

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
QL Wafer Drive
Posts: 1154
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Tetroid interfaces hardware info

Postby tofro » Sat Sep 23, 2017 10:45 am

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


martyn_hill
Trump Card
Posts: 230
Joined: Sat Oct 25, 2014 9:53 am

Re: Tetroid interfaces hardware info

Postby martyn_hill » Sat Sep 23, 2017 11:00 am

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: 2244
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Tetroid interfaces hardware info

Postby RWAP » Sat Sep 23, 2017 1:33 pm

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!



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 1 guest