Connecting a uC (PIC) to the QL

[fuasn]

i also had that problem with DSMCL already, means i thought i have to set it low when its my turn, but in-fact its the other way-round...

[fuasn]

hi all,
back to this, i now have (after tons of learning regarding tooling) a working prototype, means i can write to the PIC and also read from it.
Fixed addresses space and what not, doesn't matter, when writing smth to a matching address i get it back when reading from the address.

First thing i did is "performance test" it, using a simple basic program that does a peek_l() in a loop from 0 to 1023 with step 4. I also added one address on the PIC that gives me a millisecond timer to easier/better measure durations.

What i got was like 1.3 seconds for 1kbyte, which is quite disappointing. But when i tried the same thing with an address around 160k (decimal), which should be if im not wrong, the internal ram, i got nearly the same. My assumption thus, the basic interpreter is awfully slow... my first tries also used a peek() - one byte per iteration - which led to quite exactly 4x higher times for 1k, both on the PIC address space and internal ram, that also makes me think the basic interpreter has major impact in that "performance test".

I have also tried with a C program compiled with my SGC in place, but that seems to do exactly nothing when executing it without the SGC. Need the SGC however to run the c environment, and currently (will i ever be ?) can't use the prototype with the SGC.

So Question: is there any better way to test ram performance than just peek_l() - especially eliminating the basic interpreter impact ?

best
manfred

[martyn_hill]

Hi Manfred!

Great progress

Assuming that you are disabling DSMC so as not to wait for the 8301 ULA to provide it's own contended DTACK (accesses to contended memory space is about half the speed that the CPU can manage in the QL), then yes, SuperBASIC under QDOS is not known for its raw performance

You'll find that 99% of the time to perform a PEEK (or _L) will be the Real Number parameter stacking and manipulation. And, assuming use of a non integer FOR loop variable (the only sort available in vanilla QDOS), you can add even more overhead.

There's various approaches that come to mind to improve on that raw performance, but the biggest single improvement is running Minerva (or SMSQe) with their integer handling and generally faster interpreter (esp. SBASIC in SMSQe, which is 'semi-complied'.)

I like your approach however of interfacing a uC to the QL bus - it's something I have been exploring myself for sometime and opens up some very interesting projects...

[fuasn]

hi and thx martyn,

i have minerva running on that machine. i had a "for i=0 to 1024 step 4", will try to figure out how that "integer handling" works in sbasic. or try to somehow get the C impl working.
and yes, i'm using DMSCL to "take control"

[martyn_hill]

Hi Manfred

Well, try next:

FOR i% = 0 TO 1024 STEP 4
...
END FOR i%

It'll help a bit

[pjw]

Hi Manfred

Well, try next:

FOR i% = 0 TO 1024 STEP 4
...
END FOR i%

It'll help a bit

And here's another:

FOR i% = 0 TO 1020 STEP 4
...
END FOR i%

[fuasn]

thanks for the hints !

i tried that

Code: Select all

100 before = PEEK_L(786448)
110 FOR i% = 0 to 1023 STEP 4
120 val% = PEEK_L(170000)
130 END FOR i%
140 after = PEEK_L(786448)
150 millis = after - before
160 PRINT millis

on Minerva (no TK2) and the result seems to be quite similar, around 1200ms for the internal ram as well as for accessing PIC memory.
Interestingly again: had an error in 120 first, doing a peek instead a peek_l (so actually just reading 1/4) and that gave basically the same result...

[martyn_hill]

Hi Manfred

Ok, curious.

The error you got when attempting to assign a PEEK_L to an integer (val%) is expected - integers in QDOS are only 16-bit (and signed in SuperBASIC.)

When PEEKing a LONG, you have to stick to Real variables (just 'val').