QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Nagging hardware related question? Post here!
martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby martyn_hill » Thu Oct 13, 2016 12:52 pm

Hi Tobias - I missed one of your earlier comments...

tofro wrote:With regards to the scatter/gather algorithm used by LBYTES, this small sentence from the TK2 docs might be of importance:

If the block number received in a header is not equal to the block number required, then the header
and data block are acknowledged but ignored.


This doesn't look to me as if gather would actually work over the network with TK2.

Tobias


I have always read that statement as really meaning that, if a packet arrives with a Block Number less-than that expected - and we would only ever expect to see (block-num - 1) - then this is quietly dropped - it simply means that our last acknowledge was missed by the sender and we can safely move on.

I don't think the fs.save equivalent will actually send the packets down the wire in the order they were physically pulled from the FS device, but will serialise them enroute.

If so, the fact that the packets will only arrive down the wire in serial fashion - albeit, with an occasional dupe - suggests that the scatter-load approach of fs.load would not be a problem in itself - it would just never be needed. The issue, if I am on the right lines at all, is that fs.load will AFAIK also disable interrupts before calling the NET driver, which could conceivably get messy if, as we see in Tk2, the interrupts are switched back-on before return, regardless of previous state.

As mentioned, Minerva aims instead to preserve the interrupt status (plus other SR flags) which seems more 'right'. Could also be completely irrelevant - I'll know more tonight :-)


Martin_Head
Gold Card
Posts: 298
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby Martin_Head » Fri Oct 14, 2016 2:19 pm

Just a thought...

In your first post you say you are using some kind of non volatile ROM for TK2. Does this run at the same speed as a normal ROM would?

I know that if you run TK2 in RAM, you will have timing issues with the network, because code in RAM may/will be running at a slower speed (memory refreshes). And the timings for the network are calculated for running in ROM

Martin Head


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby tofro » Fri Oct 14, 2016 5:21 pm

Martin,

This wouldn't explain why everything but LBYTES seems to work.

Tobias


martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby martyn_hill » Fri Oct 14, 2016 6:35 pm

Yes...

I actually tried Tk2 in ROM as well as my zero-ws SRAM (made non-volatile).

I have made the assumption that ROM in the QL was always zero-ws and that the 8301 simply detects the ROM address-range and immediately enabled DTACKl, like my SRAM decoder does...

Meanwhile, I have re-assembled a slightly modified Tk2 (based on source for v2.23) to save/restore the SR like Minerva does - but doesn't make a jot of difference - LBYTES still just hangs, without ever acknowledging the scout/header from the source.

My next step is to somehow code in Tk2 the 'Minerva-way'' of handling the physical NET driver, but that will be a fairly major hack... 'Something for the weekend' as my barber used to say (I didn't understood back then!).

I'd love to hear from anyone trying this combination (Minerva + Tk2) of connecting QLs - in case its something specific to my hacked machines...

Thanks for following so far and for everyone's input...


Derek_Stewart
QL Wafer Drive
Posts: 1039
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby Derek_Stewart » Fri Oct 14, 2016 9:09 pm

Hi,

I used to connect Minvera QL + TK2 in ROM over the QLNET to another QL or QXL

The Toolkit 2 has to be ROM for Network connections. Which what I was told, so I followed the advice and it worked.


Regards,

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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby tofro » Sat Oct 15, 2016 7:32 am

Derek_Stewart wrote:The Toolkit 2 has to be ROM for Network connections. Which what I was told, so I followed the advice and it worked.



Derek,

more exactly speaking, it has to be uncondended memory. That is memory that is not slowed down by the video logic or other hindrances.

ROM, by definition, is uncontended in the QL.
Extension RAM can be uncontended, if it is zero-waitstate.

Regards,
Tobias


Derek_Stewart
QL Wafer Drive
Posts: 1039
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby Derek_Stewart » Sat Oct 15, 2016 8:29 am

Hi Tobias,

Thank you for the explanation, this was never conveyed in the 1990s, there was a lot of secret information never shared.

Just for completeness, how does the ran memory become uncontended,


Regards,

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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby tofro » Sat Oct 15, 2016 10:24 am

Derek_Stewart wrote:Just for completeness, how does the ran memory become uncontended,



A typical 68k memory cycle is an asynchronous operation
  • CPU puts a (hopefully valid) address to the bus
  • CPU asserts /AS (Address strobe)
  • memory puts the byte addressed on the data bus
  • memory signals "I'm done" to the CPU by asserting /DTACK

The ROM area in the QL "sits" directly on the data bus with the CPU - Thus it will provide data (and /DTACK) as fast as the ROM chips can, which is pretty fast and thus no delay.

The QL's internal memory (lower 128k) is shared with the 8301 and on a de-coupled part of the bus that will make the CPU wait (i.e. delay /DTACK) when the 8301 is busy with the RAM for dynamic RAM refresh cycles or clocking out the contents of video RAM to the screen circuitry. Thus, the internal RAM is about twice as slow than ROM or (potentially) external RAM. Most (simple) internal RAM extensions extend this contended RAM to the full 640k because they re-use this shared data bus.

External RAM (connected to the expansion bus) is normally not shared between the CPU and some external bus participant - It could potentially be the same speed as ROM. Unfortunately, some extensions use pretty slow RAM chips that are not able to provide data at full CPU speed - Those extensions will insert wait cycles (i.e, delay /DTACK) to accommodate for the slower RAM chips. I do re-call a test in QL World that was checking RAM speed - The fastest extensions (i.e. zero wait) were Sandy's Super-Q-Board and the Trump card. They should be able to run TK2 in RAM without any problems.

Tobias


Martin_Head
Gold Card
Posts: 298
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby Martin_Head » Sat Oct 15, 2016 10:27 am

Another thought....

What if one of the QL's system clock is not running at the right speed. That would mess up the network timing. It may be that Minerva's Network code is more forgiving the TK2's network code, so you can sometimes get away with the miss-timing.

In your first post you said that one of the QL's was issue 5. Didn't issue 5 boards have a trimming capacitor near the timing crystal. Did that affect the system clock speed?

Martin Head


Derek_Stewart
QL Wafer Drive
Posts: 1039
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Postby Derek_Stewart » Sat Oct 15, 2016 12:11 pm

tofro wrote:
Derek_Stewart wrote:Just for completeness, how does the ran memory become uncontended,



A typical 68k memory cycle is an asynchronous operation
  • CPU puts a (hopefully valid) address to the bus
  • CPU asserts /AS (Address strobe)
  • memory puts the byte addressed on the data bus
  • memory signals "I'm done" to the CPU by asserting /DTACK

The ROM area in the QL "sits" directly on the data bus with the CPU - Thus it will provide data (and /DTACK) as fast as the ROM chips can, which is pretty fast and thus no delay.

The QL's internal memory (lower 128k) is shared with the 8301 and on a de-coupled part of the bus that will make the CPU wait (i.e. delay /DTACK) when the 8301 is busy with the RAM for dynamic RAM refresh cycles or clocking out the contents of video RAM to the screen circuitry. Thus, the internal RAM is about twice as slow than ROM or (potentially) external RAM. Most (simple) internal RAM extensions extend this contended RAM to the full 640k because they re-use this shared data bus.

External RAM (connected to the expansion bus) is normally not shared between the CPU and some external bus participant - It could potentially be the same speed as ROM. Unfortunately, some extensions use pretty slow RAM chips that are not able to provide data at full CPU speed - Those extensions will insert wait cycles (i.e, delay /DTACK) to accommodate for the slower RAM chips. I do re-call a test in QL World that was checking RAM speed - The fastest extensions (i.e. zero wait) were Sandy's Super-Q-Board and the Trump card. They should be able to run TK2 in RAM without any problems.

Tobias


Hi Tobias,

If I understand this, for Toolkit 2 to function correctly, there be no sharing of the ram with the 8301 or the video ram should be separate from the main memory. Would this allow the Network to run if this is so, as Martyn is mentioning. the timings of the QL clock seems to be critical for network sync-ing.

Sounds like a hardware re-design, this could be required to use SMSQE Gold on a BBQL. SMSQE Gold uses the Super/Gold Card shadow memory paging out the QL onboard memory and leaving "holes" for the Rom Port and Toolkit 2 at $18000. Which looks like a new motherboard... but this has been done on the Aurora.

I did have paper drawing of the QL hardware split into separate modules connected by a buffered back plane, but never progressed it. Maybe this maybe an idea, to have a separate uncontended System memory board and a video ram board. Toolkit 2 could be loaded at boot time, if the network will sync okay.


Regards,

Derek

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests