SpectROM - Speccy emulator for the Pi co-pro

[jgharston]

Something prodded my memory earlier, if you ever progress to exposing the native BBC filesystem to the emulated Spectrum, there is a defined way to store the Spectrum file load/exec addresses in the BBC file load/exec addresses: FileMap.

Essentially, the 16-bit Spectrum load/exec addresses are stored in b0-b15 of the BBC load/exec addresses, and the 2-bit Spectrum file type is stored in b16-b17 of the BBC load address and exec address.

[marcusjambler]

Hi Rob

I'm struggling to get this running under ADFS
I've set this up on my master with the files in a directory in SCSI0.
SPROM loaded in SWRAM slot 4. ( inserted and reporting its presence with *h.)
Running in Native ARM it just hangs when I type zxspec

Is it beeb or DFS only?

Marcus

[RobC]

What are the file attributes on zxspec?

It runs happily from ADFS on my GoSDC and should be fine on the Master.

EDIT: An by native ARM, you do mean that you're using the 1GHz Pi core rather than the ARM2 (*FX 151,230,15)?

[marcusjambler]

What are the file attributes on zxspec?

WR attributes

Using *FX151,230,15 - 1GHz processor

[RobC]

Sorry - meant the load + execution addresses.

Also, which build of the Pi co-pro are you using?

[marcusjambler]

load + execution addresses

I dont know that ... tell me how and where to look please
Its the tinyurl download.

Pi copro version Eggeater250318

[RobC]

What do you see on screen if you do *INFO ZXSPEC?

It sounds like you're doing everything right so my only thought is that load and/or execution addresses aren't right. FWIW, this is how I load it up:

*SRLOAD SPROM 8000 4
*FX 151,230,15
[CTRL-BREAK]
*ZXSPEC

[marcusjambler]

Thanks Rob

OK *INFO ZXSPEC gives :

0000F000 0000F000 0001DFCC 04CFCA

*SRLOAD SPROM 8000 4
*FX 151,230,15
[CTRL-BREAK]
*ZXSPEC

This is the way I'm running it as well

Its a Retroclinic multiOS ( with SCSI routines reinstated by Mark ) in 3.5 mode... If that makes a difference.

Edit : I've swapped it for a MOS3.2 IC.
Still hangs at *ZXSPEC

[RobC]

That looks correct.

I'll try it on my Master - have you tried it with OS 3.2? I have a 3.5 MOS ROM somewhere but I've never fitted it!

Also, does it just hang at the prompt or does the screen go blank?

Might be worth trying *ZXINIT and *ZXSCREEN without running zxspec to see if the ROM is working.

[marcusjambler]

does it just hang at the prompt or does the screen go blank?

At the prompt... with flashing cursor.

3.2 is in now.. still hangs.

*zxinit - appears to run and goes back to a prompt.
*zxscreen - Clears screen to what looks like mode 2 and also goes to a prompt but all the characters are redefined

[RobC]

Thanks. Just tried it on my Master and I have the same issue. Not really sure why it's not working as the ROM seems okay.

I'll look into it asap and will post up a new version as soon as I've got it sorted.

EDIT: I've got an earlier version running on the Master from RAMFS and ADFS so not sure what's going on!

[jgharston]

*zxinit - appears to run and goes back to a prompt.
*zxscreen - Clears screen to what looks like mode 2 and also goes to a prompt but all the characters are redefined

The characters aren't redefined, the ULA is redefined to interpret the video memory contents Spectrum-style, but the VDU drivers are storing characters in the video memory BBC-style.

I've noticed a buglet, if you do *ZXOFF without a preceeding *ZXINIT, it tries to restore several vectors which it hasn't actually claimed.

[RobC]

Finally managed to find some time to get my BeebSCSI up and running and I have replicated Marcus's hanging issue.

However, I don't think it's anything to do with SpectROM as BAS135 and my ZX81 and Jupiter Ace emulators also hang when loaded from BeebSCSI (or the DC's RAMFS). All work correctly on my M128 when loaded from the DC's CF card under ADFS 1.53 or when loaded from floppy.

My BeebSCSI seems to be fine when the Pi co-pro is using the other cores: 6502 Elite, Panos and GEM/DOS all seemed to work under a brief test.

I've also tried it with and without VideoNuLA installed and the behaviour is the same so it looks like there may be a problem with the native ARM core and some filing systems.

Under the native ARM core with BeebSCSI, doing a *LOAD of the the ZXSPEC program and then *SAVE-ing the relevant area of memory gave a file that contained all null bytes (i.e. 0x00). I haven't been able to examine the co-pro's memory directly so the null bytes could have come from an issue with the save operation...

I'll try to do some more investigation if I can find some time - does anyone know of a ROM or utility that will allow me to view a co-pro's RAM?

Also, following a session with JGH at Wakefield, I've made some bug fixes to SpectROM and have added support for .tap files (so LOAD"" and SAVE"" work). I'll post the new version up in the next day or so.

[jgharston]

I'll try to do some more investigation if I can find some time - does anyone know of a ROM or utility that will allow me to view a co-pro's RAM?

*MDUMP on the Tube Utilities disk and BBC Utilities Disk link and link
*MDUMP FFxxxxxx dumps I/O memory
*MDUMP <>FFxxxxxx dumps CoPro memory

[RobC]

*MDUMP on the Tube Utilities disk and BBC Utilities Disk...

Many thanks - I'll do some more investigation later today.

[RobC]

Just had a thought - earlier in this thread, we mentioned that the native ARM core doesn't support 256-byte transfers through TUBE register 3. Does ADFS 1.50 use these for *LOAD etc.?

(Although, thinking about it, it seems odd that ADFS 1.53 wouldn't do the same and it works happily on my DC under the native ARM...)

[hoglet]

Rob,

I'l have a go a reproducing this as well.

If you do *HELP ARM you'll see a few extra commands available to the native ARM Co Pro:

Code: Select all

arm>*HELP ARM
ARM Tube Client 0.10
  HELP
  TEST
  GO
  MEM
  DIS
  FILL
  CRC

Dave

[hoglet]

OK, I understand what's going on now....

The Native ARM Co Pro currently only implements type 0 and type 1 transfers (it's experimental, right?)

ADFS 1.50 (SCSI) uses type 6 and type 7 transfers (256 bytes)

ADFS 1.53 (IDE) works because it uses type 0/1 not type 6/7, hence this not being discovered earlier.

I'll add this onto my TODO list to fix. This is timely because we're planning a new beta release over the weekend.

Dave

[RobC]

Thanks Dave.

Does anyone know what RAMFS on the DC uses? I'm guessing that it has a similar issue but I can't find my USB->serial cable to check with a debug build of the Pi co-pro!

[jgharston]

Does anyone know what RAMFS on the DC uses? I'm guessing that it has a similar issue but I can't find my USB->serial cable to check with a debug build of the Pi co-pro!

RAMFS uses 0/1 as it's built from the DFS code which only uses 0/1. RAMFS 1.00 has bugs in that some actions don't claim and release the Tube and a couple of loops are too tight 255 out of 256 times, causing it to fail with the 6809 and Z80 CoPros; RAMFS 1.04 fixes this. link

If the ARM Client only implements 0/1 then it will fail with NetFS as well which uses 2-byte transfers.

[hoglet]

Does anyone know what RAMFS on the DC uses? I'm guessing that it has a similar issue but I can't find my USB->serial cable to check with a debug build of the Pi co-pro!

Edit: Looks like Jonathan got in ahead of me....

RAMFS uses type 0 and type 1 transfers.

Are you having problems with it hanging on LOAD and SAVE?

There was a bug in RAM 1.00 where it didn't do a tube release, and certain co-processor (e.g. the 6809 and the Native ARM) use the interrupts from tube release to signal the end of the data transfer.

Try updating to RAMFS 1.04:
http://mdfs.net/Apps/Filing/RAMFS/RamFS104fx

Dave

[hoglet]

If the ARM Client only implements 0/1 then it will fail with NetFS as well which uses 2-byte transfers.

I'm really trying to put off implementing type 2/3 transfers in the Native ARM Co Pro, because even thinking about it makes my head hurt!

[RobC]

Thanks JGH - I managed to find my serial cable and have confirmed that RAMFS is using transfer types 0 & 1.

Looking at the co-pro memory using the built-in *MEM command (thanks Dave!), it looks like ZXSPEC isn't being loaded properly. The first half of the file (approximately) looks okay but the second half seems to be full of 0x55s. I'll check this more thoroughly after dinner.

It looks like there might be a similar issue with BAS135 as it partially runs and then hangs at the "Starting with" message.

EDIT: Ah - a quick search revealed this thread about loading files >64KB in length with RAMFS. This would explain what I'm seeing with ZXSPEC as it's about 128KB in length.

EDIT2: Sorry Dave, dIdn't see your earlier post - I'm using RAMFS 1.04. It doesn't hang on load or save but what's loaded into memory is corrupt/incomplete.

[hoglet]

Ah yes, the infamous RAMFS 64K limit!

I've just made available a first release candidate for the next release of PiTubeDirect:
viewtopic.php?p=203367#p203367

This (hopefully) fixes the issue with type 6/7 transfers in the Native ARM Co Pro.

It would be great if you could try this out, and see if it resolves the problems you were having with ADFS 1.50 and BeebSCSI.

Dave

[RobC]

Thanks Dave - will do. Will probably have to wait until after the kids go to bed now though

[RobC]

Just tested the Easter Egg RC with BeebSCSI and it's all working now

[marcusjambler]

Ive got R_TYPE running on OS3.2

However theres a new issue with OS3.5.... It hangs after a palette change

Marcus

[RobC]

I'll look into that - it hasn't been tested on MOS 3.50 as I don't have a machine with it in (I do have the ROM somewhere though!).

Could you try *SRLOADing SPROM and then doing *ZXINIT followed by *ZXSCREEN please? It would be useful to know if it hangs at either point.

[marcusjambler]

*SRLOADing SPROM and then doing *ZXINIT followed by *ZXSCREEN

Assuming Native ARM required.

They look to work :
*ZXINIT runs and goes back to prompt
*ZXSCREEN changes mode and re-maps the characters and goes back to prompt.

[RobC]

Assuming Native ARM required.

They look to work :
*ZXINIT runs and goes back to prompt
*ZXSCREEN changes mode and re-maps the characters and goes back to prompt.

Thanks - I'll have to dig my 3.50 ROM out as it seems they are working correctly.