MAME: Click (and other large ROMs)

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
KenLowe
Posts: 760
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: MAME: Click (and other large ROMs)

Post by KenLowe » Wed Sep 11, 2019 2:12 pm

Looking good =D> =D> =D>.

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Fri Sep 13, 2019 10:42 am

Updated the technical detail of the Master Smart Cartridge at viewtopic.php?f=4&t=14384&p=247421#p247421. This is now fully implemented.

I'm not aware of any other cartridges for the Master that contain additional circuitry. Currently supported are:
ABR
AQR
Click
Master Smart Cartridge
MR8000

If there are any others then let me know. I know Peartree also did a MR7200 but don't have an image of any utils that came with it.
Last edited by Pernod on Fri Sep 13, 2019 10:50 am, edited 1 time in total.
- Nigel

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

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Fri Sep 13, 2019 6:06 pm

So found the ROM for the Solidisk Mega 256 cartridge.

The cartridge contains the 8K Mega ROM and 256K RAM, not finding the RAM yet.
0035.png
To be continued ...
- Nigel

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

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Fri Sep 13, 2019 11:29 pm

The Mega 256 wasn't obvious at first, always reporting 000K and never seemingly testing for any of the RAM, so no clues as to how it was supposed to be paged.
I had the flyer from https://www.4corn.co.uk/archive/showpdf ... ard%20.pdf, but you have to read the detail for the clue.
mega256_feature.PNG
The clue is in 'Sideways RAM slot No.2.'! This thing only works when in the correct cartridge slot, and clearly expects RAM in bank 2, so lets put the ROM in bank 3 and see what happens.
0024.png
Performing a *TESTRAM is now seen to write a page selection (0-F) at &3FFF of bank 3, which selects the 16K page of RAM from the 256K total to appear in bank 2.
Emulation complete :D
Last edited by Pernod on Fri Sep 13, 2019 11:30 pm, edited 1 time in total.
- Nigel

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

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Sat Sep 28, 2019 1:09 am

The Wizard Sidewinder Expansion Board which includes the JOYROM and joystick port looks like a simple ROM expansion with added joystick, but it's not. The JOYROM, posted at viewtopic.php?f=32&t=17934, will not work in a normal ROM socket, it will crash the machine when called.

The JOYROM is 8K but only the lower 4K is paged into the ROM bank. When called with *JS ON it redirects the keyboard vector (&228) to &FD00. The upper half of the ROM is mostly empty apart from a single page of code at offset &1D00, this page is permanently mapped into JIM at &FD00.
0151.png
0152.png
0153.png
It looks like the joystick is being read from &FC05, but haven't got it working yet.
- Nigel

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

User avatar
KenLowe
Posts: 760
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: MAME: Click (and other large ROMs)

Post by KenLowe » Sat Sep 28, 2019 1:18 am

Very impressive =D> =D> =D> =D>

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Mon Nov 18, 2019 12:55 pm

I'm taking another look at the E2P, and as this is a current topic elsewhere, hope someone can clarify a few things.

My main sticking point is when and how long the IRQ line is pulsed. I know the IRQ line should be asserted when the Electron access $FCE5 (read or write) to tell the E2P to do something, but when is it cleared? The original ETI document suggests 'triggers the 15us IRQ monostable' but this makes the whole thing very timing sensitive. Is this an accurate time, or is there a better indication of when I can clear the line, maybe when the E2P accesses $FFxx?
- Nigel

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

User avatar
jms2
Posts: 2313
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: MAME: Click (and other large ROMs)

Post by jms2 » Mon Nov 18, 2019 3:18 pm

Hi there,

I just happened to click on this thread for the first time in a long while (I'm not a MAME user) and it dropped me close to your first query about E2P, which was in 2018! Sorry, I would have responded if I had known it was there.

As you have seen, John Wike is now frequenting these forums and he would have a definitive answer. However, I think the intent is to provide a 15us pulse as you have surmised. I have written a "how it works" document which I can check later. I'm sure if you provided a slightly longer pulse it wouldn't matter - it just needs to be whatever the 6502 needs to recognise a valid interrupt.

To answer your previous question, there isn't a lot of difference between the ETI version of E2P and the production version. The main issue is that the ETI article doesn't provide a clear circuit diagram, whereas there was a proper diagram in circulation (and findable on Derek Walker's Bygonebytes site).

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Mon Nov 18, 2019 9:16 pm

jms2 wrote:
Mon Nov 18, 2019 3:18 pm
I'm sure if you provided a slightly longer pulse it wouldn't matter - it just needs to be whatever the 6502 needs to recognise a valid interrupt.
This 'seems' to be the problem, the E2P doesn't respond and transfer all bytes when transferring the OS to $F800, which would infer that the Electron is trying to transfer more bytes before the IRQ has been cleared. So maybe I should be reducing the pulse time?

If I reduce the time it misses bytes and increasing the time duplicates bytes, can't find a definitive time.

From posts elsewhere I understand that the E2P NMI is used for RAM refresh, and not relevant for my emulation. Would you agree?
- Nigel

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

User avatar
jms2
Posts: 2313
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: MAME: Click (and other large ROMs)

Post by jms2 » Mon Nov 18, 2019 10:01 pm

Pernod wrote:
Mon Nov 18, 2019 9:16 pm
If I reduce the time it misses bytes and increasing the time duplicates bytes, can't find a definitive time.
Hmm, not sure. The following is the code snippet used to send a byte via &FCE5:

Code: Select all

.SendByteViaFCE5
        LDA     ($00),Y						\ Load this byte
        INC     $00							\ Inc LSB
        BNE     SkipMSB						\ Skip incrementing MSB unless needed
        INC     $01							\ Inc MSB
.SkipMSB
        STA     Host_TubeByte				\ Send byte
        LDY     #$0A						\ Delay period = 10 loops
.DelayLoop
        DEY
        BNE     DelayLoop
        RTS
You can see that it counts to 10 after sending each byte. Working out how many cycles that is might give you some ideas regarding IRQ pulse length.

From what you say, it sounds like your emulation is generating more than one IRQ per byte, if you are getting duplicated bytes?
From posts elsewhere I understand that the E2P NMI is used for RAM refresh, and not relevant for my emulation. Would you agree?
Actually, that's not right. Yes the NMI is used for DRAM refresh, but after it's done that it also checks for several IO to 2P commands, and executes them. So you must provide the NMI signal.

User avatar
jms2
Posts: 2313
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: MAME: Click (and other large ROMs)

Post by jms2 » Mon Nov 18, 2019 10:08 pm

Just thought - are you stopping the second processor clock during host accesses? You should be! If you don't stop the clock, I can see how you might get more than one IRQ pulse.

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Tue Nov 19, 2019 1:10 pm

jms2 wrote:
Mon Nov 18, 2019 10:01 pm
Actually, that's not right. Yes the NMI is used for DRAM refresh, but after it's done that it also checks for several IO to 2P commands, and executes them. So you must provide the NMI signal.
Good to know, NMI signal now implemented, pulsed periodically at 1ms intervals. Doesn't affect initial OS transfer as NMI vector is set to $FF72 which is RTI.
jms2 wrote:
Mon Nov 18, 2019 10:08 pm
Just thought - are you stopping the second processor clock during host accesses? You should be! If you don't stop the clock, I can see how you might get more than one IRQ pulse.
Not sure how I would emulate this behaviour. Can you elaborate on how not stopping the clock could produce multiple IRQ pulses?

Had another look at the original ETI article relating to the IRQ time. In the 'How It Works' section it says 'triggers the 15us IRQ monostable', but on the same page, in the Setting Up section, it says 'You should see on the scope a negative going pulse 15ms wide'. So which is it 15us or 15ms?

I'd prefer to implement the time as derived from 16MHz / x / y if you could explain the dividers in IC4/6, same for the NMI.
- Nigel

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

User avatar
jms2
Posts: 2313
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: MAME: Click (and other large ROMs)

Post by jms2 » Tue Nov 19, 2019 11:19 pm

To verify the length of the IRQ pulse will have to wait until tomorrow, but I can confirm it is simply done by dividing the 16mhz clock in ic4 and ic6.

The reason why you have to stop the clock is this: during host accesses to FRED an IRQ is generated by dividing the 16mhz clock. The same dividers also generate the cpu clock too. If the dividers continue to run, then IRQs will continue to be generated and the cpu will continue to see them. The clock is stopped by holding the dividers' CLR line.

User avatar
jms2
Posts: 2313
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: MAME: Click (and other large ROMs)

Post by jms2 » Wed Nov 20, 2019 6:37 pm

Its 15us (well, I make it 16us actually, but maybe there are some delays or something which make it 15). The divisions that take place are as shown below:
Capture.JPG

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

Re: MAME: Click (and other large ROMs)

Post by Pernod » Wed Nov 20, 2019 9:12 pm

jms2 wrote:
Wed Nov 20, 2019 6:37 pm
Its 15us (well, I make it 16us actually, but maybe there are some delays or something which make it 15). The divisions that take place are as shown below:
Thanks for confirming, and explaining the dividers. It helps me document the hardware, but still no closer to working. I'll have to setup a trace on each cpu to see where it's derailing.
- Nigel

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

Post Reply