Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_jgharston wrote:Yes, everything's preconverted, see http://mdfs.net/Software/BBCBasic/BBCTube
Z80BASIC.ROM is Z80 BBC BASIC for the BBC Z80 Tube built as a ROM image. Either load it into a sideways ROM or RAM, and if a Z80 CoPro is active then *BASIC selects it. Alternatively, if you have correctly extracted it from the archive so the load/exec address are set correctly, *Z80BASIC will load and run it from disk. The ROM image includes a Z80 disassembler, see the Z80Text file.
Z80BASIC.COM is Z80 BBC BASIC for the BBC Z80 Tube without a ROM header, runnable directly from disk, either froma CPM disk (whereupon you lose access to CPM) or from a BBC filing system.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_jgharston wrote:Odd. On Break it should have disabled 6502 BASIC and automatically entered Z80 BASIC without any intervention.
On pressing Break you should get something like this, without you having to do anything else:
It doesn't matter as, before any languages are examined, anything that is not Z80 code has its 'language' bit removed from the ROM table*, so is ignored as a language. If Z80 Basic is present and a Z80 CoPro is active, only Z80 languages are considered for selection as a language.KayjayUK wrote:I get the first two lines but the third line is just BASIC rather than Z80 BASIC. So it would seem I don't have the ROM in SWR or should 6502 BASIC be in a lower priority socket?
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_No, I'm using a BBC B. I also think I have discovered the problem, whatever mode I put the Beeb in I can't successfully use SWR. As I mentioned previously I haven't tried using it before, the ROM board is a used one I picked up, the main part of the board seems to work ok, I've had no issues with ROMs previously. As a simple initial test I have bought a couple of 6264's to see if that fixes it, if not then it's time to dust off my diagnostics skills, they're very dusty and minimal but enough I think to search out any hardware probs.jgharston wrote: but you're not using an Electron are you?
Before I got Z80 BASIC I used Rowland Waddilove's assembler translated into BBC BASIC.KayjayUK wrote:I also have the option of writing Z80 assembler using my copy of Romas cross assembler in standard 6502 mode then running it under Z80 copro, this will eliminate the necessity for Z80ROM.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_](./images/smilies/eusa_wall.gif "Brick wall"){kind=small}
Is this the ROM we are talking about?KayjayUK wrote: So is the Z80ROM corrupted, is my Pi zero software corrupted? I bought a micro sd ready programmed with the software from Kjell so I'm assuming it's correct but hey ... you never know.
So has anyone got any ideas at all ?
Darn it .... of course !! no wonder it doesn't flippin' work ... Yes, that's the one, thing is I can't put a 128 onto the WE 12 rom board can I. I could pull the board out and use the standard beeb sockets and switch S33 over but I still wouldn't have enough sockets ....hoglet wrote:Is this the ROM we are talking about?KayjayUK wrote: So is the Z80ROM corrupted, is my Pi zero software corrupted? I bought a micro sd ready programmed with the software from Kjell so I'm assuming it's correct but hey ... you never know.
So has anyone got any ideas at all ?
http://mdfs.net/Software/BBCBasic/Z80Basic/Z80ROM
For Z80ROM you need a 27128 (16K), as it's too large to fit in a 2764 (8K).
You should be able to use a 27128 in most of the sockets. It's only 14L/14H that are different:KayjayUK wrote: Darn it .... of course !! no wonder it doesn't flippin' work ... Yes, that's the one, thing is I can't put a 128 onto the WE 12 rom board can I. I could pull the board out and use the standard beeb sockets and switch S33 over but I still wouldn't have enough sockets ....
That's good, thanks.hoglet wrote:You should be able to use a 27128 in most of the sockets. It's only 14L/14H that are different:KayjayUK wrote: Darn it .... of course !! no wonder it doesn't flippin' work ... Yes, that's the one, thing is I can't put a 128 onto the WE 12 rom board can I. I could pull the board out and use the standard beeb sockets and switch S33 over but I still wouldn't have enough sockets ....
https://www.retro-kit.co.uk/user/custom ... s12ROM.pdf
If you have a CPM boot disk with the SJCCP instead of the DRCCP you can issue *commands from the CPM> prompt. See also JGHCPM1 disk.Andrewcee wrote:Had cpm running from a turbo MMC albeit have still to work out how to change MMC disks from cpm.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_Well done !Andrewcee wrote:Have succeeded running Z80 basic program on Master with Pi copro earlier today, a new first. Used half dozen lines of code looping round with calls via oscli to format & verify a dozen floppies. Definitely a 27128 needed or equivalent swr. Had cpm running from a turbo MMC albeit have still to work out how to change MMC disks from cpm. Looking forward to trying out some Z80/cpm software in due course.
Pi copro worked on my Beeb when I tried this morning, another first, so imagine Beeb will run Z80 copro on Pi no bother. Liking the Pi copro.
JGHCPM1 is a standard sequential disk image, where sector N is at offset N*B into the image, where sector N+1 is always and invariably immediately after sector N. JGHCPM1d is an interleaved disk image where sector N is at offset ((N MOD 10)+((N DIV 10) MOD 80)*20+(N DIV 800)*10)*B into the image, where sector N+1 is sometimes immediately after sector N and sometimes is N+10 sectors further on, and sometimes is N-800 sectors behind. Some people prefer interleaved disk images.KayjayUK wrote:I suppose I'm being dumb again but why a singlesequential and a double sidedinterleaved disk for the same file set or are they different ? JGHCPM1 and JGHCPM1d
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_Whilst no doubt correct, that does strike me as being a little non-obvious. So, if I understand correctly, this is about interleaving the tracks from the sides of a disk so for other's benefit.....jgharston wrote:JGHCPM1 is a standard sequential disk image, where sector N is at offset N*B into the image, where sector N+1 is always and invariably immediately after sector N. JGHCPM1d is an interleaved disk image where sector N is at offset ((N MOD 10)+((N DIV 10) MOD 80)*20+(N DIV 800)*10)*B into the image, where sector N+1 is sometimes immediately after sector N and sometimes is N+10 sectors further on, and sometimes is N-800 sectors behind. Some people prefer interleaved disk images.KayjayUK wrote:I suppose I'm being dumb again but why a singlesequential and a double sidedinterleaved disk for the same file set or are they different ? JGHCPM1 and JGHCPM1d
Wow, thank you. This is tremendous information. I've forgotten a lot that I knew in the 80's but it is coming back bit by bitCoeus wrote:
Whilst no doubt correct, that does strike me as being a little non-obvious. So, if I understand correctly, this is about interleaving the tracks from the sides of a disk so for other's benefit.....
Acorn DFS and CP/M both treat double-sided disks as two single-sided disks, assigning a separate drive ID to each and files do not span sides.
Acorn ADFS and DOS as implemented on the iBM PC treat the two sides of a double sided floppy as one medium but in slightly different ways. Imagine you have a freshly formatted ADFS disk and you go to save a file that is longer than one disk side. In this case ADFS will start writing on track 0 of the first side, immediately after the free space map and root catalogue and when it reaches the end of track 0 it will step the disk head and continue on track one. That will continue until the end of track 79 (for an 80 track drive) and then it will reposition the head back to track 0 and start writing on the second side of the disk. This arrangement is "sequential sides".
If you did the same on an IBM PC with a freshly formatted disk, writing would begin on track 0 of the first side immediately after the FAT but upon reaching the end of track 0 on that side instead of stepping the head to track 1 writing continues on track 0 of the second side. Only when that track is full would then head be moved to track 1 and writing would continue on the first side again. That would then carry on for as many tracks as necessary. This arrangement is "interleaved sides".
The Acorn ADFS arrangement has the advantage that the catalogue and some files may be readable from a double-sided disk even in a single sided drive. The IBM PC arrangement has the advantage that it is faster for reading/writing large files of several tracks because there is less head movement.
The snag comes when you decide to read all the data from a floppy as raw sectors and store it in a single file (on a hard disk) for archiving. If you want the archiver program, i.e. the one reading the floppy and writing to the image file on hard disk to run as fast as possible, which you do if you have a stack of them to do, you read the floppies using the IBM interleaved sides approach (80 head movements per double sided disk, compared to 240 with the Acorn approach) but if the source floppy is an Acorn disk and you write the sectors to the image file on the hard disk in the same order they are being read from floppy you end up with an image file with the sides interleaved which is a good archive, in that it can be written back to a real floppy fast, but is sub-optimal for use with emulators running on relatively old hardware because with emulator access confined to one side, for example on a DFS disk image, the emulator's host OS has to move the hard disk head further than if the sides had been stored in the image file consecutively (sequentially).
Possibly for that reason, JGH prefers sequential sided (SSD) image files. I don't know the full history but I suspect a significant archiving operation pre-dates the availability of good emulators on the PC so elsewhere (other than JGH's excellent mdfs.net) the interleaved side (DSD) image file is commonplace and is supported by modern emulators.
It is possible to convert between the two formats and Steve Harris's 'beeb' is one utility which has that feature. There are no doubt others too.
(pun def intended) No they don't. Acorn CP/M treats a double-sided disk as a single logical disk with 160 tracks, exactly the same as ADFS. CP/M drive A: is both sides of drive 0, CP/M drive B: is both sides of drive 1. The only oddity is that logical sectors count downwards on track 80 to track 179.Coeus wrote:Acorn DFS and CP/M both treat double-sided disks as two single-sided disks,
Ideally, when imaging a file system from physical media, you want the imaged system to be an image of the file system you've imaged. So, if the file system says that object A starts at block N, then it is at block N in the image file, not block ((N MOD S)+((N DIV S) MOD T)*2*S+(N DIV (T*S))*S) or something similar.Coeus wrote:The snag comes when you decide to read all the data from a floppy as raw sectors and store it in a single file (on a hard disk) for archiving.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_Ok, I was posting based on my 30+ y/o memory of using CP/M on a RM380Z but Wikipedia confirms my memory making reference to the " 380Z Disc System CP/M Version 2.2 Users Guide" which, in section 3.2 entitled "Disc Drive Naming Convention" says:jgharston wrote:No they don't. Acorn CP/M treats a double-sided disk as a single logical disk with 160 tracks....Coeus wrote:Acorn DFS and CP/M both treat double-sided disks as two single-sided disks,
So I checked further and it seems I have been guilty of an over-generalisation. Mapping logical records (of 128 bytes), which would have originally corresponded to a sector on an 8" disk, to physical device, track, sector is a BIOS function and different CP/M ports with different BIOSes can handle this differently.Each disc drive in a 380Z disc system can either read one side of a disc
(single-sided) or both sides of a disc (double-sided). You should check
whether your drives are 5.25-inch or 8-inch and double-sided or single-
sided. Each side of a disc drive that is operational is referred to
individually as a "logical disc drive" and is given one of the names A, B,
C, or D.
Drives A and C represent the two sides of the first disc drive, which is
always present on a 3802 Disc System,‘while drives B and D represent the
two sides of the second disc drive (Not all 380Z disc systems are equipped
with a second disc drive.) Note that only drives A and C are present in a
single-disc (double-sided) disc system while only drives A and B are
present in a double—disc (single—sided) disc system.
So, if I have got this right, and going back to my writing a large file example, upon reaching track 79 on the first side writing would continue with track 79 on the second side and then work back towards track 0.jgharston wrote:...exactly the same as ADFS. CP/M drive A: is both sides of drive 0, CP/M drive B: is both sides of drive 1. The only oddity is that logical sectors count downwards on track 80 to track 179.
I am not disagreeing with this. It all depends on whether you see the image file as just an archive, i.e. something opaque to the host system on which it has been stored., or whether you want to use it on the host, especially "use it" in the sense of having software on the host access the filesystem within that image to copy files in/out. In this latter case you are quite right that having the image file laid out in logical sector order for that filesystem makes things easier.jgharston wrote:Ideally, when imaging a file system from physical media, you want the imaged system to be an image of the file system you've imaged. So, if the file system says that object A starts at block N, then it is at block N in the image file, not block ((N MOD S)+((N DIV S) MOD T)*2*S+(N DIV (T*S))*S) or something similar.Coeus wrote:The snag comes when you decide to read all the data from a floppy as raw sectors and store it in a single file (on a hard disk) for archiving.
Unfortunately, there was no standard for how a CP/M filesystem should be represented on disc, and there is no expectation of interoperability between CP/M systems.Coeus wrote:Ok, I was posting based on my 30+ y/o memory of using CP/M on a RM380Z
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_