read / write to JIM

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

read / write to JIM

Postby dominicbeesley » Thu Nov 16, 2017 12:09 am

Before I start coding...

I'm currently working on device that exposes memory in the JIM (page &FD) are and uses the page wide paging registers. Are there any standard tools for reading / writing files to / from JIM?

D

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Thu Nov 16, 2017 11:35 am

I guess not then!

Is there anyone out there who has expansion RAM in JIM? If I knock up some tools would there be interest, any help with testing?

Also, is there an official way to work out what expansion RAM is fitted if any? I'll probably just make them work blind for now...

I'm thinking:

JLOAD <file> <jim address>
JSAVE <file> <jim address> <jim end> <exec?> or <file> <jim start>+<len> <exec?>
JMOVE <io address> <jim address> <len>
JMOVE -R <jim address> <io address> <len>

The first two would require that OSGBPB is present, I think this is true of most DFS's but not tape or ROMFS

D

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Thu Nov 16, 2017 5:17 pm

JIM really isn't for general-purpose RAM! Quite apart from anything else, it's half the speed of sideways RAM; why not use sideways RAM instead?

It's really intended for two things, one rather more niche than the other.

The first is removing the CPU card from an Acorn System and instead exposing its address space to a BBC Micro. This got called the "Cambridge Bus", and recognised that there were a variety of specialist I/O cards that people wanted to continue using, especially in laboratories. Indeed, even in the early Nineties, I found old Acorn System cards still feeding lab rats, attached to a BBC I/O podule in an A5000!

The second is implementing peripherals that need more than a few bytes of memory-mapped I/O. For example, the Music 5000 uses a few kilobytes of JIM for waveform memory and the like.

So, unfortunately, I suspect the main reason there aren't already tools for this is that people don't feel it's an appropriate or useful thing to do. /-8

cmorley
Posts: 258
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford

Re: read / write to JIM

Postby cmorley » Thu Nov 16, 2017 5:32 pm

Aren't there RAM disks which work out from JIM already and FS implementations for them? I pretty sure that's what the Datacentre does but I don't have one so can't say for sure.

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Thu Nov 16, 2017 5:38 pm

That's certainly not how I'd design a ram disk.

Note that LDA &abcd is one cycle quicker than LDA &abcd,X so it's actually more efficient to present a series of bytes through consecutive reads of one I/O location than as a page! You only want to be using JIM if genuine random access to an I/O memory space is required.

(Or, terrifyingly, if you want to run code directly from a peripheral. But if you're doing that then you really want to be in a paged ROM bank rather than on the 1MHz bus!)

User avatar
BigEd
Posts: 1490
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: read / write to JIM

Postby BigEd » Thu Nov 16, 2017 6:27 pm

Not so much terrifying as ingenious - the Torch Graduate does it, so it can operate solely from the 1MHz bus without needing a ROM on the host:
viewtopic.php?p=177386#p177386

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Thu Nov 16, 2017 6:53 pm

Gosh. I never knew that!

I can't help thinking a simple 8K EPROM for a Sideways ROM socket must have been a lot cheaper than the logic they needed to make that hack play nice on the 1MHz bus, though...

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: read / write to JIM

Postby Rich Talbot-Watkins » Thu Nov 16, 2017 7:19 pm

Just less intrusive I guess. It's plug 'n' play!

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Thu Nov 16, 2017 7:42 pm

Thanks all,

I take your point crj, but I'm not (solely) using this as expansion RAM it is a hardware item that happens to have a big chunk of RAM and it would be beneficial to be able to easily read / write files into / from that RAM by some method, preferably without using large buffers in normal IO processor RAM. I've already made it accessibly via JIM (as that was easy)...there will be other ways to access the RAM but more on that when I've got it working!

The Acorn App not for 1MHz bus notes a single 64k address space, I need a bit more than that

I know its not the fastest way of presenting the data but sometimes ease of use and ease of hardware design trumps speed. This is really for my proof of concept tests, I will make a support rom with proper load/save etc commands.

I've now started this, one final question...

I note the Datacentre uses JIM memory but only below 10000000. I'm going to make my hardware start at that address but will writing to say 10000001 just write to DC's RAM at 00000001 and corrup the RAM disc? Or does the DC know to ignore requests outside its own area?

D

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Thu Nov 16, 2017 7:59 pm

It feels deeply inelegant to me that only one device on the 1MHz bus can use that mechanism. If they'd intended it for anything other than test hardware, I'm guessing they'd have kept running through JIM pages, starting at &00, doing JMP (&FDFE) on any page where &FDFF contained &FD, until the interrupt went away.

Then again, it's not like more than one device could do anything useful. Maybe if the extended vector mechanism had supported JIM...

Looking at when the call is made, it's before sideways ROMs have been initialised, so of limited usefulness. I guess the trick to do would be:
  • Copy a tiny "boot loader" to &00
  • Point OSBYTE 247-9 at it
  • The boot loader brings loads your main block of code to &400-&7FF, like the Tube Host System
  • Enter your main block of code, which immediately issues service call 3 to initialise a filesystem, since you've hooked in before that bootup step. (Probably you set Y<>0 so it doesn't boot.)
  • Print a banner and pretend you're the current language.

It's almost tempting to make a toy which does that!

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Thu Nov 16, 2017 8:22 pm

Hmm. That fails if there's actually a second processor present, though. And there's no way I'm seeing of preventing the second processor from initialising.

Annoyingly, I see nowhere universally safe to stick the code, then: PAGE on a machine with lots of filing systems is higher than HIMEM on an Model A in MODE 4/5. Maybe put the code at &2C00-&2FFF and assume nobody will have soldered a 1MHz connector to their model A just so they can plug in your hacky thing.

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Fri Nov 17, 2017 12:49 am

Well, it kinda works...slowly. the 1MHz bus speed, is not the problem but using OSGBPB is S.L.O.W. looks like I'll need a better way of loading big chunks of data in

D

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Fri Nov 17, 2017 9:03 am

dominicbeesley wrote:I guess not then!

I must have not worken up properly yet, but you seem to have given people a negative amount of time to respond before deciding nobody was going to reply. Your first post was at 12:09, and your reply was at 11:35, half an hour earlier!

dominicbeesley wrote:Is there anyone out there who has expansion RAM in JIM? If I knock up some tools would there be interest, any help with testing?

The DataCentre has 1M of RAM page-wide RAM, and I've also got a Sprow 8M byte-wide RAM card. When updating RAMFS a couple of years ago I wrote some extended RAM load/save utilities, I'll try and find them.

dominicbeesley wrote:Also, is there an official way to work out what expansion RAM is fitted if any? I'll probably just make them work blind for now...

No. As with any "unlimited" memory the only way to find out how much is there is to probe it, writing test values at various addresses and probing to see where they occurs and don't occur. Some boards reflect in unused addresses (in the same way that on a standard BBC sideways bank 0, 4 and 8 "sees" banks 12). Some boards respond to only a set set of addresses, for instance only responding to addresses &000xxx. I haven't tested the DataCentre RAM to see what it does.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Fri Nov 17, 2017 9:20 am

jgharston wrote:
dominicbeesley wrote:Is there anyone out there who has expansion RAM in JIM? If I knock up some tools would there be interest, any help with testing?
The DataCentre has 1M of RAM page-wide RAM, and I've also got a Sprow 8M byte-wide RAM card. When updating RAMFS a couple of years ago I wrote some extended RAM load/save utilities, I'll try and find them.

I've dug them out, and put them here: http://mdfs.net/Software/CommandSrc/Utils/Memory/

*XSave <afsp> <start> <end>|+<length> (<exec> (<load>))
Save data from page-wide extended RAM in JIM.

*XLoad <fsp> (<load>)
Load data to page-wide extended RAM in JIM.

dominicbeesley wrote:I note the Datacentre uses JIM memory but only below 10000000. I'm going to make my hardware start at that address but will writing to say 10000001 just write to DC's RAM at 00000001 and corrup the RAM disc? Or does the DC know to ignore requests outside its own area?

I've just tested, and the DataCentre doesn't have restricted addressing, it reflects through unused addresses. It responds to all addresses &---xxxxx, so accessing &001xxxxx is the same as &002xxxxx is the same as &64Exxxxx etc.

If you have another extended memory device and have it earlier on the connecting cable you could make the pass-through connector only pass on addresses &000xxxxx.

dominicbeesley wrote:JMOVE <io address> <jim address> <len>
JMOVE -R <jim address> <io address> <len>

I've just realised what those last two are. The standard names for those would be as with the *SR commands:

*XREAD <main start> <main end>|+<length> <extended start>
Read data from extended memory starting at <extended start>, depositing the data in main memory at <mainstart>
Eg, *XREAD FFFF3000+5000 128000 would read 20K of data to screen memory from extended address &128000.

*XWRITE <main start> <main end>|+<length> <extended start>
Write data to extended memory starting at <extended start>, fetching the data from main memory at <mainstart>
Eg, *XWRITE 800+2000 6C400 would write 4K of data from language address 800 to extended address &6C400.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Fri Nov 17, 2017 9:41 am

crj wrote:I'm guessing they'd have kept running through JIM pages, starting at &00, doing JMP (&FDFE) on any page where &FDFF contained &FD, until the interrupt went away.
...
It's almost tempting to make a toy which does that!

There was an EPROM programmer somebody brought to ABUG Bolton a couple of years ago that did exactly this. We had to blow BASIC 1 and OS 0.10 ROMs to get it to work as the code it imported called all sorts of direct core addresses. Being OS Zero the target users may well have had the 4x4K MOS daughterboard so they wouldn't have been able to use an internal ROM - not that the MOS Zero sideways ROM support has much to say about it other than as an interesting bit of archeology. Ever wondered by the ROM header layout looks like a table of zero-terminated strings? ;)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Fri Nov 17, 2017 11:18 am

Enormous thanks JGH once again!

I wasn't being petulant in my second post - I just assumed nobody had anything JIM based...and it was 1.09am->12.35pm so I left eleven and a half hours, I'm still working on the time-travel machine but I suspect that I may need more than a 1MHz bus to drive it...

I've done a bit of digging and on the JIM front I've found: (hardware, popularity, support req)
- DataCentre - popular - yes
- Challenger OPUS 3 - ??? - no
- Sprow 8M - ??? - maybe
- Morley RAM disc - ???? - no uses different registers
- Music 2000 - ??? - ??? (doesn;t work with DC anyway)
Others?

Thanks for the tools - I had a quick look at xload and it looks to be more or less what I wrote yesterday (execpt better) but still uses OSGBPB...slow. At least on MMFS which is all I have on the test machine.

I fear I will abandon the JIM thing after the PoC stage by the looks of things as I can't see how I can interop usefully with any other hardware that uses JIM. I take what you're saying about not passing on / blocking access when the paging registers are out of range. I'm kind of doing that anyway - this hardware doesn't actually sit on the 1MHz bus but between the CPU and CPU socket. I just needed to map it into the memory map somehow and JIM/FRED seemed the best bet

I'll have to do more testing to see if the DC always resets both paging registers and if it does then if it always write all zeroes to the top 4 bits. I'd like whatever I do to be compatible with DC at least.

I'll probably just implement a quick "lock" function that blocks nPGFD while I have claimed JIM but that would preclude using OSGBPB straight to JIM...

It would have been easier if the DC and other RAM discs had used JIM as Acorn appear to have intended (i.e. only one "paging" register at FCFF (64k map) that actually selects the page-wide hardware, release bus if not your number) then had actual RAM paging registers elsewhere. We could have all played nicely together then...

I guess also that all Paging registers from all hardware must always be write-only? otherwise who would win on a read? I'll have a dig in the DC code to check for reads / inc's etc...

D

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Fri Nov 17, 2017 5:34 pm

dominicbeesley wrote:I wasn't being petulant in my second post - I just assumed nobody had anything JIM based...and it was 1.09am->12.35pm so I left eleven and a half hours, I'm still working on the time-travel machine but I suspect that I may need more than a 1MHz bus to drive it...
Weird that at this end it's claiming 12:09pm->11:35am on the same day!
dominicbeesley wrote:Thanks for the tools - I had a quick look at xload and it looks to be more or less what I wrote yesterday (execpt better) but still uses OSGBPB...slow. At least on MMFS which is all I have on the test machine.
It goes along ok here on NFS, HADFS and ADFS. Haven't tried DFS. Takes about 30sec for 64K, a 20K screen loads from DFS in about 5sec, so half the speed of a direct load seems reasonable. It's on a par with *SRLOAD.
I'll have to do more testing to see if the DC always resets both paging registers and if it does then if it always write all zeroes to the top 4 bits. I'd like whatever I do to be compatible with DC at least.
From the code I've worked with, RAMFS always selects &0xxx. It never selects anything in b23-b31 in &FCFD. So it consitantly selects the bottom 1M of the 24-bit 16M address range.
I'll probably just implement a quick "lock" function that blocks nPGFD while I have claimed JIM but that would preclude using OSGBPB straight to JIM...
Yes, you mustn't OSGBPB direct to JIM as you have no ability to tell if the filing system you're OSGBPB'ing to/from is also using JIM. You only "own" the JIM paging window if you don't JSR to anybody else, JSR out of your code - to anything at all - is an explict release of your ownership. Strictly speaking, my XLOAD/XSAVE needs PHP/SEI/PLP around the transfer code.
It would have been easier if the DC and other RAM discs had used JIM as Acorn appear to have intended
DC/etc are implemented as per the Acorn intent, &FCFF for the 256-byte page within a bank of 64K, with &FCFE and lower if implemented select what bank of 64K, etc. as in BeebEx.gif which implements a 16M address range with two latches.
I guess also that all Paging registers from all hardware must always be write-only? otherwise who would win on a read? I'll have a dig in the DC code to check for reads / inc's etc...
You're not supposed to read from them, you should keep your copy of what you've written to them elsewhere, as in the *XSave,*XLoad code which does LDA addr+1:STA latch-0:LDA addr+2:STA latch-1,etc. One of the DC registers happens to be read/write, but to be compliant code that accesses the address registers need to treat them as write-only. All address latch registers should latch whenever an address is written, so it wouldn't matter which respond to a read as they would all be responding with the same contents. Whther that works nicely electrically is another matter.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Sat Nov 18, 2017 3:47 pm

Thank JGH, I think I was being over optimistic as I've always taken the attached 1MHz bus app not as Gospel
1Mhzbus_appnote.pdf
1MHz bus app note 003, 1992
(68.88 KiB) Downloaded 11 times


jgharston wrote:Weird that at this end it's claiming 12:09pm->11:35am on the same day!

I suspect that the forum software / server / something is still operating on BST (or something like that) as I've seen odd times (wrong by 1hr) when viewing the forum on my phone.

jgharston wrote:It goes along ok here on NFS, HADFS and ADFS. Haven't tried DFS. Takes about 30sec for 64K, a 20K screen loads from DFS in about 5sec, so half the speed of a direct load seems reasonable. It's on a par with *SRLOAD.


Re OSGBPB I'm getting ~15s for 20k via OSGBPB vs 1s via *LOAD on MMFS, I suppose I've just got spoilt by using MMFS! I'll try comparisons on DFS/RAMFS later...

I've not done the OGBPB part of USBFS on the 6809 machine I'll have a look at doing a full-speed version there and look at back-porting it to MMFS if it doesn't look to complicated. It should be possible to at least detect the special case where a full sector is about to be read and just read it straight to/from destination rather than to the internal buffer then doing 256 expensive BGET/BPUTs

jgharston wrote:From the code I've worked with, RAMFS always selects &0xxx. It never selects anything in b23-b31 in &FCFD. So it consitantly selects the bottom 1M of the 24-bit 16M address range.


That's not quite the point I was getting at. If _I_ set FCFD then DC comes along and sets FCFE/FF but not FD it will trample _my_ RAM instead of writing its own RAM - not what is wanted. So I would have to reset FCFD to 0 after every transaction and not call any disk routines until I reset FCFD..

jgharston wrote:DC/etc are implemented as per the Acorn intent, &FCFF for the 256-byte page within a bank of 64K, with &FCFE and lower if implemented select what bank of 64K, etc. as in BeebEx.gif which implements a 16M address range with two latches.


Not according to the 1992 (wishful thinking, stable door, horse, bolt?) App not for 1MHz bus s.6. Maybe this wasn't followed or was a wishful retrospective plan but if this had been followed i.e. FCFF become a card select register and actual paging registers are elsewhere then all the cards could have played along nicely each having its own unique and exclusive page(s) in JIM.

It's quite clear to me that the intent (at least in that document) was that each card should have its own latch and only respond when it is being addressed.

RAM expanders would then only need take up either one page in the JIM 64k map and have their own paging registers in FRED or two pages in JIM with their RAM accessed in one page and their control registers in a second JIM page.

However, it's all academic as that doesn't seem to be how the DC works.

jgharston wrote:Yes, you mustn't OSGBPB direct to JIM as you have no ability to tell if the filing system you're OSGBPB'ing to/from is also using JIM. You only "own" the JIM paging window if you don't JSR to anybody else, JSR out of your code - to anything at all - is an explict release of your ownership. Strictly speaking, my XLOAD/XSAVE needs PHP/SEI/PLP around the transfer code.


Yes, I realise that now, I'd thought that the &EE/App not scheme above was still possible but alas no.

I'll add write only registers in my code, always protect _my_ RAM by using a value other than 0 at FCFD and resetting to 0 after each transaction and not calling any OS calls in that time....if there are interrupts that access JIM though they will slip through unless I always disable interrupts. which might not be a bad idea.

And here's some pictures of my beeb (currently labotomised with a DE0 nano acting as CPU+test hardware+16Mb JIM RAM) and Logic port analyzer monitoring A[15..0],D[7..0],RnW,etc

20171114_002028-s.jpg


And here's my rather distracting assistant testing out the Master after the PSU was refitted.

20171112_140042-s.jpg


D

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Sat Nov 18, 2017 11:43 pm

dominicbeesley wrote:RAM expanders would then only need take up either one page in the JIM 64k map and have their own paging registers in FRED or two pages in JIM with their RAM accessed in one page and their control registers in a second JIM page.

Actually, if you're trying to address much more RAM than can sensibly be paged directly into JIM (i.e. more than, say, 4Kbytes) there's a lot to be said for taking a single page of JIM, using half of it for RAM read/write and the other half for paging.

If your control registers are in a separate FRED page, switching to bank X of your RAM requires:

Code: Select all

LDA #ctrlpage
STA &FCFF
STX &FD__
LDA #datapage
STA &FCFF

If they're in the same page, you just STX &FD__. Keeping within one page of FRED would bank-switch twice as often, but take only 2.5µS instead of 9.5µS each time.

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Sat Nov 18, 2017 11:54 pm

jgharston wrote:DC/etc are implemented as per the Acorn intent, &FCFF for the 256-byte page within a bank of 64K, with &FCFE and lower if implemented select what bank of 64K, etc. as in BeebEx.gif which implements a 16M address range with two latches.

Is there any clear documentation of exactly what Acorn's intent was when trying to map lots of memory onto the 1MHz bus? Their intent in that respect would surely have to be compatible with the more common use case of claiming just a few pages of JIM and interacting with the bus only when those pages had been selected?

In that spirit:
  • &FCFF would always be the highest-order addressing word, no matter how much memory was being addressed.
  • &FCFE would be the next highest-order addressing word, and so on.
  • Just like accesses to JIM itself, a device would only heed accesses to &FCFE when it had been selected in &FCFF.

So if addressing 20 bits you could claim JIM pages &80-&8F for 16 possible values of A[19:16]. If (and only if) one of those JIM pages had been selected, writes to &FCFE would latch A[15:8].

Anything else seems to make a mess of attempts for multiple devices, particular multiple devices with different addressing depths, to play nice together on the 1MHz bus?

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Sun Nov 19, 2017 12:34 am

It would depend on what kind of access (block transfers for say a RAM disc, or what I'm doing) or more random transfers whether an extra few us per 256 accesses or would justify losing the ability to do a quick zero test on an index register. But I take your point.

I'd say the app note (see attachment above) is pretty explicit. However I'm not sure when this app note was released or whether it received a wide audience.

Extended pages &00 to &7F are reserved for Acorn use, pages &80 to &FF may be freely used by special
applicatons. The paging register will be reset to &00 on power-up and BREAK.

crj
Posts: 315
Joined: Thu May 02, 2013 4:58 pm

Re: read / write to JIM

Postby crj » Sun Nov 19, 2017 2:58 am

It's explicit about a lot of things, yes. Though unless I've missed something major it's entirely silent on any kind of approved way to access more than 64K of I/O space?

While in theory you could map 32K by taking the entire upper half of JIM that does strike me as a tiny bit antisocial. Is there any record of who does what with the 1MHz bus that's at all up to date?

User avatar
1024MAK
Posts: 6788
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: read / write to JIM

Postby 1024MAK » Sun Nov 19, 2017 9:59 am

I think that maybe Acorn may not have fully thought the idea through, given how much RAM cost at the time that the Beeb was designed.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
Pernod
Posts: 997
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: read / write to JIM

Postby Pernod » Sun Nov 19, 2017 11:40 am

crj wrote:Is there any record of who does what with the 1MHz bus that's at all up to date?

I've been looking at various devices over the past few months for emulating them in MAME. The following are all devices that use JIM that I know of:

Torch Graduate
- Paging register at &FCFF to page into JIM 32 pages (8K) of ROM. At startup page 0 of ROM is paged into JIM and executed from OS with JMP (&FDFE) to download into BBC RAM.

Music 5000/3000
- Paging register at &FCFF to page into JIM 8 pages (2K) of RAM. Both devices use JIM, 5000 when 0xFCFF & 0xF0 = 0x30, 3000 when 0xFCFF & 0xF0 = 0x50.

Opus Challenger 3
- Paging registers at &FCFE, &FCFF to page into JIM 2048 pages (512K) of RAM disc.

Morley RAMdisc
- Paging registers at &FC00-02 to page into JIM 4096 pages (1MB) of RAM disc. Not fully understood so may be inaccurate.

Millipede PRISMA-3
- Paging register at &FCB7 to page into JIM 32 pages (8K) of non-volatile RAM, containing palette, etc.
Last edited by Pernod on Sun Nov 19, 2017 12:24 pm, edited 4 times in total.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
hoglet
Posts: 6613
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: read / write to JIM

Postby hoglet » Sun Nov 19, 2017 11:56 am

Pernod wrote: 3000 when 0xFCFF & 0xF = ?

It's actually 0xFCFF & 0xF0 = 0x50

(i.e. testing bits 7..4)

See this thread:
http://www.stardot.org.uk/forums/viewto ... 08#p183808

Dave

User avatar
Pernod
Posts: 997
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: read / write to JIM

Postby Pernod » Sun Nov 19, 2017 12:06 pm

hoglet wrote:
Pernod wrote: 3000 when 0xFCFF & 0xF = ?

It's actually 0xFCFF & 0xF0 = 0x50

Thanks, surprised I missed that, especially with it being so recent.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Sun Nov 19, 2017 1:01 pm

dominicbeesley wrote:That's not quite the point I was getting at. If _I_ set FCFD then DC comes along and sets FCFE/FF but not FD it will trample _my_ RAM instead of writing its own RAM - not what is wanted. So I would have to reset FCFD to 0 after every transaction and not call any disk routines until I reset FCFD..

Whenever you want to use JIM, you must set all the latches. You must not assume they have been left as you set them, and must not assume they have been set to any sane state. As soon as the CPU ceases to execute your code you have explicitly given away ownership of JIM and ownership of whatever you have set the latches to.

ie:
\ my code is running
LDA addr+1:STA latch-0:LDA addr+2:STA latch-1:LDA addr+3:STA latch-2
\ I own JIM
blah blah
\ I own JIM
blah blah
JSR somewhere else :\ I HAVE EXPLICITLY GIVEN AWAY OWNERSHIP OF JIM
\ when the CPU gets back here I DO NOT OWN JIM, I HAVE TO EXPLICITLY RESLECT ALL THE LATCHES
LDA addr+1:STA latch-0:LDA addr+2:STA latch-1:LDA addr+3:STA latch-2
\ I own jim, for as long as the CPU is executing my code
blah blah blah
RTS :\ I NO LONGER OWN JIM
(*note)

You should assume other software does not obey the rules and should set the latches into a consistant state when you relinquish them, thet best thing to do is set them all to zero. As some drivers may assume there's only 64K of extended memory and only ever frob &FCFF, and some may assume there's only 16M and only frob &FCFF and &FCFE the safest thing to do is always set all latches to &00 whenever your code relinquishes ownership. "Relinquish ownership" is very non-strict. Ansolutely any departure from your code is relinquishing ownership - calling OSWRCH, calling OSBYTE, strictly speaking allowing IRQs to happen. You should keep you JIM access code in atomic chunks surrounded by PHP/SEI/PLP.

Also, I think it's best to set the latches in the order latch-2, latch-1, latch-0, so if there is, for example, a 64K board with only one latch (or 16M with two latches), but that latch is reflected in multiple I/O locations, then later writes select ever decreasing ranges. Otherwise, with a 64K board writing eg &000080 to latch-0, latch-1, latch-2 would result in page &00 being selected, not page &80. (or simla' with 16M/2-latch board)

jgharston wrote:DC/etc are implemented as per the Acorn intent, &FCFF for the 256-byte page within a bank of 64K, with &FCFE and lower if implemented select what bank of 64K, etc. as in BeebEx.gif which implements a 16M address range with two latches.

...
RAM expanders would then only need take up either one page in the JIM 64k map and have their own paging registers in FRED or two pages in JIM with their RAM accessed in one page and their control registers in a second JIM page.[/quote]
I think the intent, in the memory-restricted days, was that each board would have a maximum of 64K, and each board would be selected by their own latch. Which utimately is the same as saying a greater-than-64K board is selected by both latches. That's how the Control Universal boards from the early 1980s worked.

jgharston wrote:Yes, you mustn't OSGBPB direct to ... Strictly speaking, my XLOAD/XSAVE needs PHP/SEI/PLP around the transfer code.

Yes, I realise that now, I'd thought that the &EE/App not scheme above was still possible but alas no.[/quote]There is something in that AUG that says the &EE ram copy is useless as that's actually keypress data, and no software actually uses &EE as a ram copy anyway.

(*note some of the above more explicitly describes than needed to make it clear for other readers coming back later - I've spend the last few days bashing my head against faulty USB documentation where just one post of the above type would have cleared everything up)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Sun Nov 19, 2017 1:04 pm

crj wrote:
jgharston wrote:DC/etc are implemented as per the Acorn intent, &FCFF for the 256-byte page within a bank of 64K, with &FCFE and lower if implemented select what bank of 64K, etc. as in BeebEx.gif which implements a 16M address range with two latches.
Is there any clear documentation of exactly what Acorn's intent was when trying to map lots of memory onto the 1MHz bus? Their intent in that respect would surely have to be compatible with the more common use case of claiming just a few pages of JIM and interacting with the bus only when those pages had been selected?
I've got stuff at home that I can't get to from this laptop, I'll find it when I'm looking for something else! A lot of this JIM stuff was essentially farmed out by Acorn to Control Uviversal/CUBE

Extended pages &00 to &7F are reserved for Acorn use, pages &80 to &FF may be freely used by special applicatons. The paging register will be reset to &00 on power-up and BREAK.

That never happens! Most of Acorn's JIM documentation was written in the very early days and never actually used to base anything on, not even the MOS., and seems to have been quietly pushed to one side and hoped to be forgotten about, until somebody then goes and gives copies to Brady/Dickens/Holmes.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

dominicbeesley
Posts: 464
Joined: Tue Apr 30, 2013 11:16 am

Re: read / write to JIM

Postby dominicbeesley » Sun Nov 19, 2017 3:30 pm

Thanks all, interesting stuff

Thanks Pernod for the details.

JGH, all points taken, looks like the EE/select scheme was never actually used: why it was still on a seemingly current App note dated 1992 I've no idea! I should have remembered the EE being used for OSBYTE&79 and the keyboard routines as its not that long since I ported them! (In my defence I've carefully used labels rather than ZP addresses as my memory is just not up to remembering such things with any accuracy).

jgharston wrote:Whenever you want to use JIM, you must set all the latches. You must not assume they have been left as you set them, and must not assume they have been set to any sane state. As soon as the CPU ceases to execute your code you have explicitly given away...


My difficulty with this is that it is never future proof. If I come along with another hardware board that usess FCFC as another paging register this stops working. It's the resetting everything to 0 _after_ use by software that knows how many paging registers it had changed (and disabling interrupts) that is the key I think. A real shame as a proper guard scheme and isolated pages in a 64k map (with a copy of the top paging reg in EE) could have allowed a lot of hardware to inter-operate and use interrupts.

Anyways, I think for any production system I will avoid JIM altogether as it just seems to be a bit of a minefield also as I can't read/write direct to from JIM using OSGBPB it defeats my original purpose of hoping to be able to read direct from disc into my extra memory without my support ROM having to claim an extra page at startup...For now I'll just load to page 9/A/B as a buffer or use the bottom half of the stack.

The other option might be (as suggested earlier) to somehow block access to JIM (after my hardware is selected) by not passing on nPGFD on the 1MHz bus...as the hardware is sitting in the CPU socket it could also send a phoney address to the system (say FFFF) and have access to _my_ JIM be at 2MHz insteasd of 1.

JGH I'd be very interested to see any older materials on this (and other interfacing specs) from Acorn!

D

User avatar
jgharston
Posts: 2756
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: read / write to JIM

Postby jgharston » Sat Nov 25, 2017 9:36 pm

dominicbeesley wrote:My difficulty with this is that it is never future proof. If I come along with another hardware board that usess FCFC as another paging register this stops working. It's the resetting everything to 0 _after_ use by software that knows how many paging registers it had changed (and disabling interrupts) that is the key I think. A real shame as a proper guard scheme and isolated pages in a 64k map (with a copy of the top paging reg in EE) could have allowed a lot of hardware to inter-operate and use interrupts.

Yes, I had this at the back of my mind as I was digging through the keyboard driver code writing my USB keybaord driver. Lots of documentation warns that &EE is keyboard workspace and using it as a JIM latch RAM copy would interfer with it. How it remained in Acorn documentation for so long is a puzzle, especially as Acorn seemed to have offloaded JIM-type stuff to CUBE - but then in writing the USB driver I've uncovered more incorrect documentation!

I also came to the same conclusion as you, any software that uses JIM should set all the latches to a safe address afer using them, and the address that is safest across all possible uses is zero. I've also come up to the same ownership problem with the USB keyboard driver. The driver talks to the USB during interupts, but how does it know a foreground process isn't also talking to the one single USB port? No existing USB software sets any sort of guard while using the USB port, so a background process has no way of knowing that it's going to jump into the middle of the foreground doing something.

Demo viewable in glorious blurrovision here.

dominicbeesley wrote:For now I'll just load to page 9/A/B as a buffer or use the bottom half of the stack.

An easier method is to stack your workspace:
TSX:TXA:SEC:SBC #128:BCC errNoStackSpace
TAX:TXS :\ Claim 128 bytes on the stack
INX:LDY #1 :\ XY=>128 bytes of workspace on the stack
TSX:TXA:CLC:ADC #128:TAX:TXS :\ Release 128 bytes on the stack

or this, which is more flexible for different amounts of space:
TSX:TXA:TAY :\ X=Y=current SP
SEC:SBC #128:BCC errNoStackSpace
TAX:TXS :\ Claim 128 bytes on the stack
TYA:PHA :\ Push old SP
INX:LDY #1 :\ XY=>128 bytes of workspace on the stack
PLA:TAX:TXS :\ Pop old SP

Demo code here.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_


Return to “hardware”

Who is online

Users browsing this forum: mlouka and 9 guests