1MHz bus and JIM interoperability

discuss both original and modern hardware for the bbc micro/electron
dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

1MHz bus and JIM interoperability

Post by dominicbeesley » Fri May 31, 2019 12:35 pm

Over the past few years hardware for the 8bit Acorn machines has started to proliferate. It is likely that the rate will increase in the near future with the various breakout boards and raspberry pi, fpga, etc dev boards that have recently become available.

Two of the sticking points for fully realising the possibilities of the 1MHz bus are: address space in FRED is limited and the differing interpretation of the methods for using the JIM page-wide addressing scheme. This has lead to compatibility problems between devices. i.e. the M5000 and DataCentre, if used together cause corruption on the DC.

I've spent a lot of time thinking about this and over the past couple of weeks migrating some of my existing designs to this scheme to test the theory and so far it seems to work.

I'd welcome any comments from the wider community and whether this scheme would work and any holes in the plan. Thanks to JGH and Hoglet for the feedback so far.

I'm still testing this out, over the next few weeks I hope to come up with firmware fixes for the DC and RAMFS to use this scheme.

D

Code: Select all


1 MHz Bus - JIM page-wide access revised protcol
================================================

rev 0.6 20200321
        Spelling mistakes and grammar
rev 0.5 20190610
        M500/0 doesn't deselect at reset
rev 0.4 20190607
        New DataCentre/RAMFS200
rev 0.3 20190531
        Device registers in JIM;
rev 0.2 20190530
        Added JIM boot; Minor textual corrections; added beebex-1
rev 0.1 20190528
        Typos and corrections from Hoglet; Explain &EE usage; Outline original
        App note, include URL; Add M3000 devno; Add Sprow RAM disc; rule R6
        added
rev 0.0 20190528
        New document

Abstract
========

The 1MHz Bus for the BBC Micro Computer Systems has a facility for providing an
extended addressing scheme using a per-device 8-bit latch (&FCFF) and a page of 
address space "JIM" at &FD00-&FDFF. [This is also available via the Electron and 
Master cartridge interface]. See the app note below for more details of JIM and 
FRED memory mapped devices.

The application notes and documentation from Acorn have been, over the years,
been interpreted by different hardware implementers in a number of contradictory
ways which has led to compatibility issues between devices.

This document sets out a set of rules which if followed will allow 
interoperability between new hardware that follows these rules and some existing
devices that follow some (if not all) of these rules.

It is hoped that this document will be followed to allow new devices to be 
mutually compatible. This is more pressing than ever with the likely 
proliferation of devices enabled by the various FPGA, RPI and breakout boards 
for the 1MHz bus and cartridge slots.

This specification does not attempt to cover aspects of the 1MHz bus other than
those related to JIM interoperability.

It is also hoped that address clashes in FRED may be avoided by devices 
presenting their main registers in JIM rather than FRED. 

Original App Note
=================

The Acorn Application Note 003 iss 1 from 16th Jan 1992 outlines a scheme much
like the one proposed below but does not make explicit how devices should 
interoperate. 

[http://chrisacorns.computinghistory.org.uk/docs/Acorn/AN/003.pdf]

Proposal
========

The following rules if followed allow interoperability including interrupt 
driven devices and drivers.

Note: there is no provision in these rules for two processes (i.e. current 
language and an interrupt routine device driver) to access the same device at 
the same time. That would require device/application specific rules for 
preservation of any extended paging registers and is beyond the scope of this
protocol.

Rules
=====

Definitions
-----------
A)      &FCFF is treated as a “device select latch” rather than a paging 
        register, the registers from FCFE downwards may, optionally, be used 
        to select a page within a device's address space and operate as 
        "extended paging registers"
B)      &FCFE...&FCFC extended paging registers within the device's address 
        space.
C)      Zero page register &EE is used as a shadow register for &FCFF (much like
        &F4 for the ROM paging register).

Required rules
--------------

R1)     Devices MUST only respond to JIM accesses if their device no. has been 
        written to FCFF. Any writes to FCFF of non matching device numbers must 
        deselect the device.
R2)     Drivers MUST save EE before writing either EE or FCFF
R3)     Drivers MUST write EE BEFORE writing FCFF
R4)     Foreground tasks MUST write EE before writing FCFF
R5)     Interrupt drivers MUST restore FCFF from saved EE after use
R6)     All devices shall be normally deselected at boot **subject to O7**


Optional rules
--------------

O1)     Devices MAY offer read access to FCFF but MUST ONLY do so when they have
        been enabled and MUST return their device no complimented 
        [this allow probes for hardware]
O2)     Additional paging registers may be added should there be a need for an 
        address space > 256 bytes in JIM. By convention the paging registers are
        at FCFE downwards. The paging registers may be at other addresses if 
        desired. 
O3)     Devices SHOULD ignore writes to paging registers at FCFE down
        unless FCFF has been set with their unique dev no. 
        [Devices may ignore this but then any interrupt could corrupt the 
        registers so any code that uses JIM would need to disable interrupts 
        and not cause NMIs to be safe]
O4)     Devices MAY offer read access to their paging register(s) but ONLY when 
        they have been enabled if they are at FCFE down
O5)     For preferance devices SHOULD only resond to a single device number to
        preserve address space. 
O6)     Drivers may (subject to allocation) partially decode the FCFF register
        and hence respond to a range of addresses. However, this is strongly
        discouraged to preserve address space.
O7)     A single device on the bus MAY select itself on reset and hold the IRQ
        line low to initiate a "JIM boot" whereby the device supplies a vector
        at &FDFE. A device that implements JIM boot must:
                - ensure it is the only device to do so
                - provide a user interface (jumper/button) to enable the 
                  function
O8)     Devices SHOULD preferably present their other hardware registers within
        their JIM (possibly extended) address space. This would preserve space
        in the FRED region and increase interoperability.

Queries
-------
?)      Endianness: should the convention for paging registers be big-endian or 
        little endian. I suspect big endian as that matches current usage for
        DC, Xload/Xsave? Also, this logically follows as extended address spaces
        extend from 8, 16, 24 to 32 bits.
?)      Use of EE: the location EE gets used by the MOS during the keyboard 
        routines for 3-key rollover. However, it is only ever read by the MOS
        and experimentation has shown that no ill effects occur when it is 
        written. However, this has not been 100% confirmed. The M5000's maturity
        would seem to bear this out.


Appendix A - device no.s
========================

00-1F   Avoid - current DC / RAMFS implementations crash this region         
30-3F   Music 5000
50-5F   Music 3000
D0      Dossytronics 1M Paula Board for Hoglet 1MHz bus/FPGA
D1      Dossytronics CPU / Blitter board 
DC      NEW: Updated DC firmware RAMFS 2.00
F0-FE   Reserved for future extended addressing
FF      Reserved as a safe "disable" device number


Appendix B - current / legacy interpretations
=============================================

Some brief notes appear below on existing non-conformant or partially conformant
hardware.

DataCentre / RAMFS 1.00, 1.01, 1.02, 1.03, 1.04
-----------------------------------------------
Non conformant: breaks rules R1, R2, R3, R4, R5

The RAMFS roms write to memory in the 00-1F device ranges.
The DC responds to any addresses causing any writes by any other device drivers
to any addresses to potentially corrupt DC memory.

Status: Actively looking to have a firmware update to address this in 2019

DataCentre / RAMFS 2.00
-----------------------
Conforms to rules R1, R2, R3, R4, R5, R6, O1, O2, O3, O4, O5

This is still in testing: Known issues EEPROM registers at FCFA-FCFC


Music 5000/3000 / Ample
-----------------------
Conforms to rules R1, R2, R3, R4, R5. 
Breaks R6

The M5000 appears to only respond to read/writes in the range 30-3F.
The Ample ROM already preserves FCFF in EE as per the Acorn App Note.

The M3000 behaviour has not been fully verified yet.

Dossytronics Blitter, Paula
---------------------------
Conforms to all rules and options O1, O2, O3, O4, O5

Control Universal BEEBEX
------------------------
Non conformant: possibly nonconformant depending on attached device

Sprow RAM disc
--------------
Unknown - unlikely to conform from description and an inspection of a 
disassembly of RAMFS 1.20

Others...?
----------


Last edited by dominicbeesley on Thu Apr 30, 2020 12:18 pm, edited 1 time in total.

dp11
Posts: 1136
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dp11 » Fri May 31, 2019 7:37 pm

I think IRQs when FCFE downwards is used may need some thought.

User avatar
jgharston
Posts: 3998
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: 1MHz bus and JIM interoperability

Post by jgharston » Fri May 31, 2019 8:10 pm

My first thoughts before waking up properly, is it is in contradiction to how everything in existance works.

While I put the kettle on, here's my investigations of JIM usage: http://mdfs.net/Docs/Comp/BBC/Hardware/JIMAddrs

Code: Select all

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

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Fri May 31, 2019 8:29 pm

jgharston wrote:
Fri May 31, 2019 8:10 pm
While I put the kettle on, here's my investigations of JIM usage: http://mdfs.net/Docs/Comp/BBC/Hardware/JIMAddrs
I think you have the addresses for the Music 3000 and 5000 the wrong way around.

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Fri May 31, 2019 10:00 pm

Thanks all. Brief replies as I'm phone bound at the moment

dp11, if devices only update their extended paging registers when they are selected then there is no need to save them. Devices that always accept writes would need to disable interrupts..

Jgh. In what ways do you think it contradicts? It is compatible with the app note and how the m3000/5000 work. I'll have to get hold of the software for the other things and disassemble. Having said that the aim is not really backwards compatibility... nothing I've seen so far can interoperate other than the m5000! My aim with this is to come up with an improved spec that actually works for more than one device at once for _new_ devices.

Before going away this morning i tried moving all the blitter, sound, dma, registers to live in jim rather than try and squeeze into fred. With the change of a few characters in the vhdl it got rid of a whole load of problems qnd free up a whole load of addresses. Plus i could run two soundcards at once!

Thanks hoglet, I'll fix that on Sunday evening

I had a quick look and the DC has plenty of room left on the cpld so ill have a go at that next week. Just getting the DC and M3000/5000 to work together would be a start!

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Fri May 31, 2019 10:21 pm

dominicbeesley wrote:
Fri May 31, 2019 10:00 pm
Thanks hoglet, I'll fix that on Sunday evening
My comment was directed at JGH's document. Your document is correct:

Code: Select all

30-3F   Music 5000
50-5F   Music 3000

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Fri Jun 07, 2019 6:47 pm

Hello,

I've now managed to shoe-horn the extra stuff into the DataCentre CPLD to allow interop:
- FCFF is now device select, the magic number for the device is &DC
- FCFE, FCFD are the paging registers as before
- RAMFS has new boilerplate code on entry that stacks the existing value of &EE and inserts a shim to restore on exit

JIM RAM and FCFE, FCFD only respond when FCFF has been written with &DC any other value disables them. FCFF if it has been written with &DC will read as &23 (compliment of &DC)

None of this has been exhaustively tested yet but on my test rig with the blitter card (on device # &D1) interop seems to work. I haven't had a chance yet to test with other items as I can't find a 34 way cable with enough plugs or sockets so will have to wait for Farnell. It's likely that there are bugs in the RAMFS so please backup anything precious before trying any of this! I've tested it with IDE/ADFS and it seems to work but I'd recommend unplugging any drives for now just in case until more testing has been undertaken. Specifically any hacked versions of ROMS using the DC memory as scratch space will need reworking to use the new JIM registers.

I'd be very grateful if anyone with a DC and Music 500,5000 etc could give this is try out. You will also need a Xilinx programmer and know how to use it to flash the cpld on the DataCentre.

The files are all on my GitHub at https://github.com/dominicbeesley/DataCentre

The .jed file for flashing the cpld is in the PCB/newjimapicpld folder.
The rom to use is in RAMFS/RAMFS200.bin

D

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Sun Jun 09, 2019 2:19 pm

Do I take the silence as a lack of interest or just no takers for testing? I don't want to spend more time on this if nobody is bothered for it. I'll just get it good enough for my own purposes

D

User avatar
Elminster
Posts: 4107
Joined: Wed Jun 20, 2012 9:09 am
Location: Essex, UK
Contact:

Re: 1MHz bus and JIM interoperability

Post by Elminster » Sun Jun 09, 2019 4:08 pm

I am timed limited myself, sounds interesting in having a fixed standard. Does it have be a real M5000 or could you use a fake one? I only have the DC but happy to ‘fix it’ in the name of standards. Just don’t have a real m5000, but I did have a few 1mhz projects kicking around in my head (where they usually stay), so following the thread.

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Sun Jun 09, 2019 4:19 pm

I'll try to do some testing of the new CPLD this week.

Do feel free to remind me if it doesn't seem to have happened.

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Sun Jun 09, 2019 9:33 pm

Thanks both,

I just wanted to gauge whether there was any interest at all in the interop/jim thing or the DataCentre fixes. If there is then I'll carry on. I need to start to prioritise and finish some of my many projects! Hopefully this should work with a real or an FPGA Music xxx

Dave, I'd be grateful for any feedback!

Dom

User avatar
SimonSideburns
Posts: 539
Joined: Mon Aug 26, 2013 9:09 pm
Location: Purbrook, Hampshire
Contact:

Re: 1MHz bus and JIM interoperability

Post by SimonSideburns » Sun Jun 09, 2019 11:05 pm

I have both a Music 500 (or is it 5000, I never know) and a DataCentre (external). I was going to suggest I bring them to the next Abug as I have just booked a table, but I don't know anything about updating firmware so would need someone with experience to help.
Just remember kids, Beeb spelled backwards is Beeb!

User avatar
Elminster
Posts: 4107
Joined: Wed Jun 20, 2012 9:09 am
Location: Essex, UK
Contact:

Re: 1MHz bus and JIM interoperability

Post by Elminster » Sun Jun 09, 2019 11:31 pm

I will be at Cambridge, I do have a xlinix programmer, but I do need to remember to install software on new/old laptop, before hand. Can be a pain getting it working sometimes.

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Mon Jun 10, 2019 10:42 am

Thanks both,

I won't be able to make ABUG but I will try and get some more testing done before then and get an ABUG release ready

D

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 12:15 am

I did a bit more testing this afternoon and evening. I don't have a real M500/0 so I used Hoglet's FPGA board. I discovered a few problems with that which Dave has now incorporated in his core so if you want to use it you'll need to update to the latest version.

So far testing has gone ok (other than some problems with my machine in general). I've not done thorough testing of all drives on the DataCentre but Drive 0 (which is the one that I think got clobbered by the M5000) doesn't look to get corrupted.

I'll try and do some more thorough testing tomorrow and check out more of the other DataCentre functions including running it over the Tube but so far, so good!

D

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 11:02 am

dominicbeesley wrote:
Sun Jun 09, 2019 9:33 pm
Dave, I'd be grateful for any feedback!
I've done a bit of testing this morning, of the following configuration:
- Master 128
- Internal Pi Co Pro running Egg Eater
- DataCentre Issue 2 - reprogrammed with dcjimapi.jed from your github repository
- Beeb 1MHz Bus FPGA Adapter with the latest Music 5000 design
- RamFS 2.00 - from your github repository
- ADFS 1.53 - from my ADFS github repository

I've tried the following:
- Boot Panos from ADFS 1.53 of a Compact FLASH device
- Boot Dos Plus / Gem from ADFS 1.53 of a Compact FLASH device
- Import disc images into all 4 drives
- Boot the Music 5000 System Disc from RamFS and play something
- Export disc images from all 4 drives, and run md5sum to verify there was no corruption

The only issue I've found so far is that there is some kind of conflict between the Owl Logo from Music 5000 and RamFS 2.00. The conflict only happens on soft break. I'll try to investigate this further.

The Owl Logo code is here:
https://github.com/hoglet67/Beeb1MHzBus ... wl/owl.asm

The Owl Logo uses the break intercept vector to run some code later in the reset sequence, after the VDU has been initialised. This code is run from &FDxx using the break intercept vector. I suspect what is happening is that a service call is being made to Data Centre, which is then writing to &FCFF. Probably I need to look at having the Owl Logo code copy itself into RAM. Or, as the Owl Logo is not actually displayed on a Soft Break, try to determine this earlier and exit.

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 12:12 pm

Thanks for the testing Dave!

I think that it's my fault that owl isn't working: I made it deselect the jim page forever after the first write to FCFF maybe that was wrong and it needs to reassert itself when its device number is written to FCFF, I didn't disassemble the code so assumed once it had done its stuff it was done.

Either:
- the boot code should set &EE to its own page JIM dev no (255 I think?) if not any service calls to the DC (or other devices) will not set it back
- FF was used as the device number this is not normally an advisable "device number" for device probing (bus often stuck at FF, 00) but maybe I should add this to the spec as a special case boot device page number that should only work if you're enabled for boot (by whatever means). Boot devices are really an outlier! [FF vhdl snippet below]

Or:
- alternatively make the boot logo code copy itself to the bottom of stack space and run there?

Other:
- I'd recommend making the owl logo thing an opt in rather than an opt out as two devices with any sort of boot thing is not going to work. (It's a shame that though the Acorn recommendations for physical connections was to have an in and out socket on each board they didn't daisy chain IRQ then boot devices could have been written to pass on to the next...)

TOP of the head change to allow page back in - not only allow re-select if "owl" i.e. boot enable is set

Code: Select all

bus_interface_fc : process(clke)
    begin
        if falling_edge(clke) then
            if rst_n = '0' then
                if owl = '1' then
                    owl_page  <= '1';
                    irq_n <= '0';
                else
                    owl_page  <= '0';
                    irq_n <= '1';
                end if;
            elsif pgfc_n = '0' and bus_addr = x"ff" then
                if rnw = '0' then
                    if bus_d = x"FF" and owl = '1' then
                      owl_page <= '1';
                    else
	              owl_page  <= '0';
	            end if;
                else
                    irq_n <= '1';
                end if;
            end if;
        end if;
    end process;

top of the head changes to owl:

Code: Select all


DEVNO=&FF

.reset1
   ;; Clear the interrupt reset interrupt
   LDA &FCFF
   LDA #DEVNO
   STA &EE

On a side note I've been having problems with a corrupted USB causing the *IMPORT command to go haywire - printing random stuff on the screen and crashing. Is this a known issue or something I've introduced? Either way I'll try and track down where it's going pop and apply a fix.

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 12:26 pm

Dominic,

I've got to the bottom of the Owl Logo issue.

What happens is the following:
- Soft break is pressed
- MOS reset code at &E364 starts running
- MOS tests for interrupt during reset sequence by briefly enabling interrupts
- An interrupt is taken (Music 5000 is asserting IRQ to enable the Owl Logo)
- MOS generates a service call 05 ("Unrecognised Interrupt") to each ROM (because the ROM table at &2A1 is not cleared on soft break)
- RamFS receives a service call and runs the following code:

Code: Select all

EE89 : 20 03 80 : JSR 8003       : A=05 X=07 Y=80 SP=F1 N=1 V=0 D=0 I=1 Z=1 C=0
8003 : 4C F6 9C : JMP 9CF6       : A=05 X=07 Y=80 SP=EC N=1 V=0 D=0 I=1 Z=1 C=0
9CF6 : 20 D3 BB : JSR BBD3       : A=05 X=07 Y=80 SP=EA N=1 V=0 D=0 I=1 Z=1 C=0
BBD3 : 08       : PHP            : A=05 X=07 Y=80 SP=E9 N=1 V=0 D=0 I=1 Z=1 C=0
BBD4 : 08       : PHP            : A=05 X=07 Y=80 SP=E8 N=1 V=0 D=0 I=1 Z=1 C=0
BBD5 : 08       : PHP            : A=05 X=07 Y=80 SP=E7 N=1 V=0 D=0 I=1 Z=1 C=0
BBD6 : 08       : PHP            : A=05 X=07 Y=80 SP=E6 N=1 V=0 D=0 I=1 Z=1 C=0
BBD7 : 48       : PHA            : A=05 X=07 Y=80 SP=E5 N=1 V=0 D=0 I=1 Z=1 C=0
BBD8 : 8A       : TXA            : A=07 X=07 Y=80 SP=E5 N=0 V=0 D=0 I=1 Z=0 C=0
BBD9 : 48       : PHA            : A=07 X=07 Y=80 SP=E4 N=0 V=0 D=0 I=1 Z=0 C=0
BBDA : A5 EE    : LDA EE         : A=00 X=07 Y=80 SP=E4 N=0 V=0 D=0 I=1 Z=1 C=0
BBDC : 48       : PHA            : A=00 X=07 Y=80 SP=E3 N=0 V=0 D=0 I=1 Z=1 C=0
BBDD : A9 DC    : LDA #DC        : A=DC X=07 Y=80 SP=E3 N=1 V=0 D=0 I=1 Z=0 C=0
BBDF : 85 EE    : STA EE         : A=DC X=07 Y=80 SP=E3 N=1 V=0 D=0 I=1 Z=0 C=0
BBE1 : 8D FF FC : STA FCFF       : A=DC X=07 Y=80 SP=E3 N=1 V=0 D=0 I=1 Z=0 C=0
...
BC0D : 08       : PHP            : A=05 X=07 Y=80 SP=EF N=0 V=0 D=0 I=1 Z=0 C=0
BC0E : 48       : PHA            : A=05 X=07 Y=80 SP=EE N=0 V=0 D=0 I=1 Z=0 C=0
BC0F : 8A       : TXA            : A=07 X=07 Y=80 SP=EE N=0 V=0 D=0 I=1 Z=0 C=0
BC10 : 48       : PHA            : A=07 X=07 Y=80 SP=ED N=0 V=0 D=0 I=1 Z=0 C=0
BC11 : BA       : TSX            : A=07 X=ED Y=80 SP=ED N=1 V=0 D=0 I=1 Z=0 C=0
BC12 : BD 04 01 : LDA 0104,X     : A=00 X=ED Y=80 SP=ED N=0 V=0 D=0 I=1 Z=1 C=0
BC15 : 85 EE    : STA EE         : A=00 X=ED Y=80 SP=ED N=0 V=0 D=0 I=1 Z=1 C=0
BC17 : 8D FF FC : STA FCFF       : A=00 X=ED Y=80 SP=ED N=0 V=0 D=0 I=1 Z=1 C=0
BC1A : BD 03 01 : LDA 0103,X     : A=34 X=ED Y=80 SP=ED N=0 V=0 D=0 I=1 Z=0 C=0
BC1D : 9D 04 01 : STA 0104,X     : A=34 X=ED Y=80 SP=ED N=0 V=0 D=0 I=1 Z=0 C=0
BC20 : 68       : PLA            : A=07 X=ED Y=80 SP=EE N=0 V=0 D=0 I=1 Z=0 C=0
BC21 : AA       : TAX            : A=07 X=07 Y=80 SP=EE N=0 V=0 D=0 I=1 Z=0 C=0
BC22 : 68       : PLA            : A=05 X=07 Y=80 SP=EF N=0 V=0 D=0 I=1 Z=0 C=0
BC23 : 28       : PLP            : A=05 X=07 Y=80 SP=F0 N=0 V=0 D=0 I=1 Z=0 C=0
BC24 : 28       : PLP            : A=05 X=07 Y=80 SP=F1 N=0 V=0 D=0 I=1 Z=0 C=0
BC25 : 60       : RTS            : A=05 X=07 Y=80 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=0
EE8C : AA       : TAX            : A=05 X=05 Y=80 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=0
EE8D : F0 05    : BEQ EE94       : A=05 X=05 Y=80 SP=F3 N=0 V=0 D=0 I=1 Z=0 C=0
MOS detects an interrupt using Reset, and indirects via FDFE.

Code: Select all

F8CF : 6C FE FD : JMP (FDFE)     : A=7F X=FF Y=80 SP=FD N=0 V=1 D=0 I=1 Z=0 C=0
FFFF : FF       : ???            : A=7F X=FF Y=80 SP=FD N=0 V=1 D=0 I=1 Z=0 C=0
This jumps into the weeds, because &FCFF is currently 00, so the Owl Reset Handler code is paged out.

The issue arises because &EE (the shadow Jim ID latch) does not have a defined value on reset, and so restoring it doesn't reselect Owl Logo ROM.

This issue only happens on soft break, because on other breaks the ROM Table at &2A1 is cleared earlier in the reset sequence.

Any thoughts about this?

I can see a couple of possible fixes.
1. Update RAMFS 2.00 to not write to &FCFF unless it's a service call it is actually going to handle.
2. Update the Music 5000 Owl Logo implementation to ignore writes to &FCFF until after the &FDFE vector has been fetched

Neither seems very elegant.

I've just tested (2) and it seems to work and fix the issue.

Any thoughts on this?

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 12:59 pm

I think we crossed over, see what I said above. I'd been over enthusiastic pruning your vhdl, reenable the FCFF=FF owl enable and write FF to EE - simple and fits with the spec

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 1:02 pm

Thinking about this again maybe the boot device should be device number = 0 as this is what EE gets set to at reset so your VHDL would change to and no need to change the logo code!

Code: Select all


bus_interface_fc : process(clke)
    begin
        if falling_edge(clke) then
            if rst_n = '0' then
                if owl = '1' then
                    owl_page  <= '1';
                    irq_n <= '0';
                else
                    owl_page  <= '0';
                    irq_n <= '1';
                end if;
            elsif pgfc_n = '0' and bus_addr = x"ff" then
                if rnw = '0' then
                    if bus_d = x"00" and owl = '1' then
                      owl_page <= '1';
                    else
	              owl_page  <= '0';
	            end if;
                else
                    irq_n <= '1';
                end if;
            end if;
        end if;
    end process;


User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 1:15 pm

dominicbeesley wrote:
Tue Jun 11, 2019 12:59 pm
I think we crossed over, see what I said above. I'd been over enthusiastic pruning your vhdl, reenable the FCFF=FF owl enable and write FF to EE - simple and fits with the spec
I'm not sure your earlier fix will work. Did you manage to test it?

The crash happens before any of the Owl Reset Code ever gets a chance to run.

It's the very first JMP (&FDFE) call that goes wrong, because the Service Call &05 occurs prior to this, and ends up writing &00 to &FCFF.

Dave
Last edited by hoglet on Tue Jun 11, 2019 1:15 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 1:18 pm

I think your second fix might work in this case, but can &EE be guaranteed to always be set to &00 after reset?

I don't see where in a soft reset that happens.

Dave

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 1:25 pm

hoglet wrote:
Tue Jun 11, 2019 1:18 pm
I think your second fix might work in this case, but can &EE be guaranteed to always be set to &00 after reset?

I don't see where in a soft reset that happens.
OK, I found the place where ZP (including EE) is cleared.

But what about existing devices that use this mechanism? There were one or two I think.

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 1:42 pm

I'm not sure about the other devices - as far as I know there is an EEPROM programmer which requires MOS 0.9 - I really don't think that is worth worrying about.

Not sure what else - I suspect they will never play nice with other devices but if there's something widely used it might be worth it. I think the Torch Graduate uses this mechanism but I suspect that that would never play nice with other JIM devices?

I was half tempted to rule the boot thing out but lets try the "deliberate select" and "device 0" out and if that works its a start!

D

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 2:15 pm

dominicbeesley wrote:
Tue Jun 11, 2019 1:42 pm
I was half tempted to rule the boot thing out but lets try the "deliberate select" and "device 0" out and if that works its a start!
Yes, that does work in all the cases I've tried so far.

I'm reasonably happy with this for now, so I've just pushed a new version.

It would be nice to get rid of the "device 0" bit, but I don't quite see how. My previous attempt (ignore FCFF writes prior to the FDFE vector fetch) worked, until you removed the IRQ jumper. Then it caused a conflict with Data Centre.

Dave
Last edited by hoglet on Tue Jun 11, 2019 2:17 pm, edited 3 times in total.

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 3:16 pm

I can't really think of a simpler way that doesn't require changes either to the MOS or a lot of messing around. This way the outlier (bootable devices) has to do a tiny change whilst everything else just works the same at start up as at any other time.

If a bootable device wanted to operate on a number other than 0 it could always use the same trick (i.e. claim the break vector) and install a shim in memory to call later and (re)select its device after the service calls are finished

D

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 3:35 pm

dominicbeesley wrote:
Tue Jun 11, 2019 3:16 pm
If a bootable device wanted to operate on a number other than 0 it could always use the same trick (i.e. claim the break vector) and install a shim in memory to call later and (re)select its device after the service calls are finished
I don't think that works, because the unrecognised interrupt service call (A=05) can happen before the FDFE vector is called for the first time. So it's not possible to reliably run any code.

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 5:40 pm

Mmm, are you sure the FDFE thing looks to happen _before_ the roms are catalogued no? (Not at my machine to check just now).

I've run into a slight problem - the MUS151 ssd from 8bs.com. Some of the tunes refuse to play but I can get "SONNY" to work but after that RAM FS is wiped! (not sure why yet) Maybe these discs have a different AMPLE player on them?

User avatar
hoglet
Posts: 9228
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: 1MHz bus and JIM interoperability

Post by hoglet » Tue Jun 11, 2019 6:10 pm

dominicbeesley wrote:
Tue Jun 11, 2019 5:40 pm
Mmm, are you sure the FDFE thing looks to happen _before_ the roms are catalogued no? (Not at my machine to check just now).
The issue only happens on a soft break, because:
- the ROM table (&2A1) is not explicitly cleared on soft break
- it likely still has valid contents from prior to the soft break

So when the CLI/SEI sequence is done on soft break, the unknown interrupt really does generate a series of service calls (these come from the Beeb's interrupt handler)

Dave

dominicbeesley
Posts: 1054
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: 1MHz bus and JIM interoperability

Post by dominicbeesley » Tue Jun 11, 2019 7:34 pm

Ah, bugger, is the owl logo really important? :(

Hang on though &EE _will_ have been cleared at DA56 _before_ interrupts are enabled at DA77 so a well behaved interrupt routine should, if it uses JIM, set EE and FCFF back to 0 after they're done and thus allow the auto-boot to work so long as it is DEVICE=0?!? (or am I missing something by a mile, I need a sleep)

D

Post Reply

Return to “8-bit acorn hardware”