The Sinclair QL Forum

FYI

I ran it on a BBQL just now (the only thing non standard is the vDrive and vMAP. vDrive was attached but not initialised (I ran your bas prog from good ole mdv1_).

With MGG German ROM it was 162 +/- 1.5%
With JS ROM it was 159 +/- 3.05%

On my normal setup with Minerva and Gold Card it was 733 +/- 2.77%

Just updated the table. So I doubt vDrive would change anything since it doesn't add to the ROM but vMap does I believe...I can try and put the test on an old MDV and then re-run it but it will still have the Hermes chip...not sure that would matter since it deals with I/O stuff.

Interesting that JSU ROM is faster. Perhaps difference between European and US clock rates to deal with PAL vs NTSC? Though at 50 vs 60 that should make the JS ROM come up at around 140, not 159...

bwinkel67 wrote:Just updated the table. So I doubt vDrive would change anything since it doesn't add to the ROM but vMap does I believe...I can try and put the test on an old MDV and then re-run it but it will still have the Hermes chip...not sure that would matter since it deals with I/O stuff.

Interesting that JSU ROM is faster. Perhaps difference between European and US clock rates to deal with PAL vs NTSC? Though at 50 vs 60 that should make the JS ROM come up at around 140, not 159...

Code: Select all

CONFIGURATION                   CYCLES/SEC     +/- %    SPEED      REMARKS
---------------------------     -----------    ------   ------     ------------------------------------------------------
Ql 128ko JSU                    168            .296     x1         BBQL JSU with Hermes & vDrive (no vMap)
Ql 128ko JS                     159            3.05     x1         BBQL JS with vDrive & vMap
Ql 128ko MGG                    162            1.5      x1         BBQL MGG with vDrive & vMap
GC QL under QDOS                733            2.77     x4.5       (not sure which ROM) with vDrive & vMap
SGC QL under QDOS               1864           .25      x11        No extra multitasking from me.
SGC QL with SMSQ/E              8440           .11      x50        " " ROMdisc and Hermes.
Compaq, 1core, QPC2, 2.8Ghz     173894         37.2     x1035      Very variable timings due to monocore multitasking.
Asus, 3core, QPC2, 1.9Ghz       138683         4.0      x825       Triple core means better variability when multitasking.
"     "      "     "            ?              ?        ?          C++ code runs 400 tmes faster than superbasic version !
QLAY2, iMac 2011/Win7           1431           .935     x8.5       Speed 1000 Delay 120
QLAY2, iMac 2011/Win7           30341          1.43     x180       Speed 100000 Delay 0


Yes, the vMaps would be a bit of a pain to remove! When I have another completely original QL on the go (I've got another MGG and a UK version but not sure what ROM it has) I'll try it again as I now have a cart with it on. The 733 GC result was with Minerva ROM.

Finally done with the semester so I can start adding more features. In the meantime, while I was stuck in grading purgatory I kept playing Minesweeper on the ZXSimulator. I tired of having to get up to hit "M" to mark a mine as I used a joystick otherwise. So I changed the interface making the fire button (space) change modes and then using left/right to mark mines and up/down to clear them. So when not in that mode you move the cursor. This way you can play the entire game sitting back and only using the joystick.

Here is the BASIC that will run on ZXSimulator (it won't run in SuperBASIC):



Here is the intro screen explaining it:



I think next will be to add planet hopping to Elite_bas to complete that demo game. Then on to add new features to ZXSimulator. The first task will be to figure out how to find the size of a file without wasting time and reading it twice.

I finally set up my TS1000. I had forgotten how bad the RF modulation on the old TS1000/ZX81's were. I had to do some adjustments to make it a clear as possible. The QL RF modulator is so much better. I may have to do the composite mod on the TS1000. The EightyOne emulator lets you simulate the old screen interference so I recreated something similar to what I'm getting. I also have my original ZX81 that I haven't unboxed and wondering if its screen will be better.




In any case, I did some timings and had some surprising results. With this code, BBQL comes in 3rd about 2.7 time slower than actual TS1000. EightyOne is almost twice as fast as TS1000 which is surprising since I thought it is supposed to be pretty close to realtime esp since EightyOne is running at the lower frame-rate. This test is a bit contrived as I'm trying to squeeze the most out of the TS1000 speed-wise.

• EightyOne running at 50fps for the ZX81 - 2 second
• Actual TS1000 w/16K Ram Pack - 3.5 seconds
• QLAY2 running ZXSimulator (speed 120/delay 1200) - 10.5 seconds
• Unexpanded QL running ZXSimulator - 9.5 seconds
  

This next example has different results, now BBQL is 2nd only to the EighyOne emulator and actually beats the TS1000 hardware.

• EightyOne running at 50fps for the ZX81 - 1.30 second
• Actual TS1000 w/16K Ram Pack - 2.15 seconds
• QLAY2 running ZXSimulator (speed 120/delay 1200) - 1.70 seconds
• Unexpanded QL running ZXSimulator - 1.60 seconds
  

I think ZXSimulator is slightly slower than the EightyOne emulator but it may now actually be on par with the actual hardware TS1000 when you start adding the various commands that make up most BASIC programs. Of course once I add floating point we will see how it fares.

bwinkel67 wrote:I finally set up my TS1000. I had forgotten how bad the RF modulation on the old TS1000/ZX81's were. I had to do some adjustments to make it a clear as possible. The QL RF modulator is so much better. I may have to do the composite mod on the TS1000. The EightyOne emulator lets you simulate the old screen interference so I recreated something similar to what I'm getting. I also have my original ZX81 that I haven't unboxed and wondering if its screen will be better.

It would depend upon the ULA version. The first version didn't have a "backporch" in the video signal which means that TVs can't determine the reference black-level correctly. In fact, because it doesn't put the signal to zero TVs take full brightness as being the black-level of the signal and adjust it appropriately, meaning that the display is extremely dim. You can either switch the ULA or there are modifications and boards available which will add a "backporch" to the signal, these generally fit in the modulator can and replace the insides, giving "composite"* video out.

*it's not really composite video as it's merely a luminance signal.

So I tried my old ZX81 and a broken TS1000 that I just kept the motherboard for parts and both have unusable screens where it's basically black on black. Without the RAM pack, the working TS1000 has almost a perfect picture on a Toshiba LCD monitor/TV. When adding the RAM pack it gets more distorted but definitely nice black on bright white. The cheap composite fix may not give me better than that but there is a more comprehensive one that might I think.

I was finally able to recover my ZX81/TS1000 game BATTLESHIP that I wrote as a teenager. I had submitted it for publication and Gladstone Electronics had sent me a reply that they were in the process of crafting a contract and boom, Timex pulled out of the US market (the whole process took 3-4 months so had I been a year earlier this might have appeared on Cassette's for the TS1000).

I made two small changes to work with the ZXSimulator. My PAUSE is uninterruptible, which I need to fix since you can break pausing with any keystroke on the ZX81/TS1000 so I removed it and replaced it with an IF/GOTO (line 90). Also, grabbing INKEY$ is better if you do it once and assign to a variable so I added that, although it was working without that fix (line 962). The one ZXSimulator bug is when comparing strings via = in an expression which turns + into concatenation of strings so had to add VAL (line 970 and 975). But that's it, otherwise it is unchanged.

Note that once I got it loaded into the TS1000 through an audacity captured wave file on my desktop, I took 30 screen shots with my iPhone and typed it in since the EightyOne emulator refused to read the actual audio (and the Java based conversion tool gave me endless errors with no hope in sight). So perhaps there are still a few typos that I need to fix but I did play through a few games (finding like half a dozen typos that caused the game to crash) and I beat the computer once and it beat me once. What's nice about this (and l likely why it was publishable) is that the game has a nice pace and the computer talks to you so there is a bit of a "script" that I created for the user. When I create stuff now, user experience be damned but I guess as a teenager I thought about it.

This game is almost 40 years old:





Update: fixed some typos but found no bugs. Also updated the picture since some of the text on the computer's end was off by 2 spaces.

Latest version of ZXSimulator. A few small but helpful changes:

• Changed file reading to be a bit more efficient. It now determines size of file, allocates that memory, and reads it in
  
  
  • This has sped up file loading a lot
  • Before I was constantly resizing my internal store and copying from small to large which was mucking up the heap
  • Now I can load larger BASIC files with less memory (i.e. BBQL can load 13K Battleship_bas)
  • Need to figure out a better way to determine file size -- right now I read it twice (whats a good way to get file size via TRAPS?)
    
• PAUSE now can be aborted. I basically pause for 5 milliseconds and check for key presses (should likely eat those presses as well but am not)
• Listing was broken for rare case of double-wrap where the 3rd line left a single character
• Display wasn't quite centered -- fixed
• String concatenation and equality now works properly and won't muck up in lengthy expressions with mixed types
  

Here is the zip:



You will see that the source file has been zipped as the distribution has gotten a bit too big to fit into 128KB of MDV storage. So you have a zip file inside of a zip file :-/ You'll have to unzip src_zip if you wanna take a look of the C code for the simulator.

Note that I added a 4th program, my Battleship_bas game that I wrote as a teenager in the early 80's on my ZX81. I reclaimed it and left it mostly as is. I had to type it in since I was only able to load the tape onto a TS1000 and then took screen shots. I think I fixed all the typos. I changed a few lines where I was doing this:



To the code below as it works better with how INKEY$ is implemented via a QL TRAP.



So without this you can be pressing a key and it just doesn't always registers it, especially on a fast machine (QLAY2 for me). So assigning the INKEY$ to the K$ variable seems to capture more key presses. I did the same thing in the Ball_bas program previously. Note that INKEY$ isn't all that great on a ZX81/TS1000 either.

I may change the Battleship_bas program like I did with the minesweeper game and tie both setting ships and picking spots to joystick port 1 so you don't have to use the keyboard. Still, I designed it this way (I think -- been almost 40 years) because that's how battleship works, giving coordinates. I must have decided that being able to have a moving/blinking cursor was also cool since setup is done that way.

BTW, there is a bug during setup that when you cross an already placed ship, the cursor will overwrite it. Oh, and if you try to set a ship off the board nothing happens...sometimes that can be confusing -- I should have added an error message.

bwinkel67 wrote:(whats a good way to get file size via TRAPS?)

Read the file header into a buffer with trap #3, d0 = $47. You only need to load the first 14 bytes (16 for DDL2). If you use the SuperBASIC buffer then precede the trap #3 with a trap #4 to make it a6 relative. The file length is the first item in the buffer. It includes the 64 byte header length so youll need to subtract this for the net file length. Check out the Technical guide for the exact details.