AtoMMC2 ROM

[oss003]

ATOMMC ROM:

This is a tempory storage for updates of the AtoMMC ROM until the retrosoftware hardware page is ready.

AtoMMC v2.9:
- Initial release

AtoMMC v2.91beta:
- *RUN error SYNC? ERROR 135 in program solved by erasing the parameter option
- *CHAIN <basic-filename> command added for updating TOP and DIM pointer before running program

AtoMMC v2.91beta1:
- *RUN error SYNC? ERROR 135 fixed (with the help of hoglet ), works again with parameters

AtoMMC v2.91beta2:
- Restore OSRDCH vector after executing *MENU
- Stack overflow in SDROM and GAGS interpreter solved.

AtoMMC v2.94:
- Upgrade to latest version AtoMMC ROM with previous changes
- SDROM + GAGS ROM stack overflow corrected

AtoMMC v2.95: *** RELOADED ***
- Correct filename loading, not on #140
- Corrected version text in *HELP

AtoMMC v2.97 beta2:
- Random Access File handling working in Atomulator and real Atom
- Tested at 1/1,8 MHz

AtoMMC v2.97:
- Random Access File handling working in Atomulator and real Atom
- Tested at 1/1,8 MHz

AtoMMC v2.98:
- Fixed a bug with C=1 OSFIND returning an error (BRK) rather than 0 on a non-existent file

AtoMMC v2.99:
- Added Initial Tube Support
- Removed *FATINFO command
- Fix a bug with LODVEC/SAVVEC

AtoMMC v3.00:
- Support 1/2/4MHz operation
- Separate builds for AVR and PIC, A000 and E000
- Optimize code base to make room for more features
- Add *FATINFO command back
- Add *REN command (needs 2C firmware)
- Add *MKDIR command (needs 2C firmware)
- Add *RMDIR command (needs 2C firmware)
- Allow / as path separator
- Support single files and wild cards in *INFO
- Fix broken error checking in *SAVE
- Fixed a bug in *SAVE where length could be calculated incorrectly

AtoMMC v3.01:
- Fixed incorrect tube transfer address for SAVE

atommc2-v3.0.1.zip

(145.45 KiB) Downloaded 20 times

sddos-v3.25.zip

(2.2 KiB) Downloaded 169 times

ramrom.zip

(38.83 KiB) Downloaded 17 times

Greetings
Kees

[hoglet]

Hi Kees,

Is the source to AtomMMC available somewhere?

I'm trying to debug an error handling problem with the Atom Basic 2 port I'm messing with, and I think it's probably AtomMMC doing something naughty, like jumping back to the Atom Basic Interpreter in some cases. It would be much easier to track this down with the source code!

Dave

[oss003]

Hi Kees,

Is the source to AtomMMC available somewhere?

I'm trying to debug an error handling problem with the Atom Basic 2 port I'm messing with, and I think it's probably AtomMMC doing something naughty, like jumping back to the Atom Basic Interpreter in some cases. It would be much easier to track this down with the source code!

Dave

Hi Dave,

I've attached the source of the AtoMMC v2.94 ROM.
In the source of Atomulator, you can find the source of the PIC firmware.

Greetings
Kees

[hoglet]

Hmm, I think I understand the problem I'm having with BBC Basic 2 and errors produced by AtomMMC.

It looks like in AtomMMC that the error handler is implemented actually implemented in Atom Basic, so the OS call will never return.

Code: Select all

reportFailure:
   lda   #<errorhandler
   sta   $5
   lda   #>errorhandler
   sta   $6
   jmp   $c2f2

errorhandler:
   .byte "@=8;P.$6$7'"
   .byte SQ
   .byte "ERROR - "
   .byte SQ
   .byte "$!#D5&#FFFF;"
   .byte "IF?1|?2P."
   .byte SQ
   .byte " - LINE "
   .byte SQ
   .byte "!1& #FFFF"
   .byte $0d,0,0
   .byte "P.';E."
   .byte $0d

For example, when I'm in BBC Basic and there is a NOT FOUND error (for example), the Atom Error handler runs, and eventually the Atom Basic END code, which hangs because there isn't a valid Atom Basic program.

If there is a valid basic program, then control simply returns to the Atom Basic interpreter, as can be seen by it getting confused with the tokens of BBC basic:

This seems quite a fundamental problem, and will affect other languages.

Do you think there is any possibility of fixing this behaviour, so that errors end up hitting a BRK, which would be handled by the current BRKVEC handler, which I think work would better than re-entering Atom Basic. I guess that would mean replacing the current error handler with one written in machine code.

Dave

[oss003]

Hi guys,

AtoMMC2-v2.2.9.5 is equal to version 2.95 and is reloaded with the right text in *HELP at the top of this topic.

Greetings
Kees

[hoglet]

Hi Kees,

Is the SDDOS source included in the AtomMMC 2.9.5 ZIP the latest?

The version is 3.24, and there seems to be a 3.25 binary floating around.

I want to have a go at building an AVR version for the AtomFpga.

Dave

[oss003]

Hi Dave,

Is the SDDOS source included in the AtomMMC 2.9.5 ZIP the latest?
The version is 3.24, and there seems to be a 3.25 binary floating around.

IIRC the source is not included in the AtoMMC 2.9.5 ZIP file.

During backup of my USB stick, it crashed and normally I work from this USB stick ....
I could restore a lot of software from the last backup but not all. I must have a look on my home PC's if there is another copy of SDDOS 3.25 somewhere. Luckily I spread my software often on my other PC's and in the STH forum but have to check where.

Otherwise I must make a new original v3.25 from the binary vs the source of v3.24.

Greetings
Kees

[hoglet]

Sorry to hear that Kees - hope you didn't loose anything else.

As far as I remember, the main fix was a bug in DCAT:
http://www.stardot.org.uk/forums/viewto ... 419#p77496

This was what I was trying to fix before sending a pre-programmed ROM off to Charlie at the weekend.

But it's not a big deal, as AtoMMC is better!!!

Dave

[oss003]

Hi Dave,

This is what I found:

Code: Select all

;=================================================================
; INT.INC
; v01.07 !!!!!!!!!!! FINAL VERSION FOR SDROM v1 !!!!!!!!!!!!!!!!!!
; v02.00 !!!!!!!!!!! FINAL VERSION FOR SDROM v2 !!!!!!!!!!!!!!!!!!
; v02.10 !!!!!!!!!!! FINAL VERSION FOR SDROM v2.1 !!!!!!!!!!!!!!!!
; v02.20 !!!!!!!!!!! FINAL VERSION FOR SDROM v2.2 !!!!!!!!!!!!!!!! 
; v03.00 !!!!!!!!!!! AtoMMC2 interface version !!!!!!!!!!!!!!!!!!!
; v03.10 !!!!!!!!!!! *DVER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
; v03.20 !!!!!!!!!!! *RUN file and *file problem solved !!!!!!!!!!
; v03.21 !!!!!!!!!!! *RUN file and *file problem now solved !!!!!!
; v03.22 !!!!!!!!!!! Corrected stack overflow interpreter !!!!!!!!
; v03.24 !!!!!!!!!!! PHS - Merged in routines for AVR/AtomClone !!
; v03.25 !!!!!!!!!!! *RUN file and *file problem now solved !!!!!!
;=================================================================

Kees

[hoglet]

Hi Kees,

You might want to check these changes (from the SDROM 2 branch):
https://github.com/hoglet67/AtomFpga/co ... 2df78c56a3

(specifically: in copy_parm1)
- CMP #0D ; Copy until #0D
+ CMP #$0D ; Copy until #0D

Plus these later ones:
https://github.com/hoglet67/AtomFpga/co ... 2aa40b4cbc
https://github.com/hoglet67/AtomFpga/co ... cfb529329f
https://github.com/hoglet67/AtomFpga/co ... 85f27c8ad9

Dave

[oss003]

Ok, reversing historie .....

Thankx

[oss003]

Hi Dave,

I did find this one.

Kees

[hoglet]

Code: Select all

diff -r 3.24/int.inc 3.25/int.inc
12a13
> ; v03.25 !!!!!!!!!!! *RUN file and *file problem now solved !!!!!!
1152a1154
> 	sta $9e
1715c1717
<                 .byte 	"SDDOS V3.24 [TURBO]  (C)KC 2011"
---
>                 .byte 	"SDDOS V3.25 [TURBO]  (C)KC 2011"

That adds this fix:
https://github.com/hoglet67/AtomFpga/co ... 2aa40b4cbc

There were two changes to the SDROM2 branch after this:
https://github.com/hoglet67/AtomFpga/co ... cfb529329f
https://github.com/hoglet67/AtomFpga/co ... 85f27c8ad9

I guess we should figure out if these also affect the SDROM 3 branch.

(Is the right name SDROM or SDDOS?)

Dave

[oss003]

Dave,

actually it is the SDDOS ROM, it has the standard Atom DOS ROM commands but works with disk-images on an SD-card instead of real disks.

IIRC the version history is like this:

- v1.x, SDDOS for a VIA SD-card interface
- v2.x, SDDOS for the AtoMMC interface
- v3.x, SDDOS for the FPGA (upgraded v1.x)

Right?

Greetings
Kees

[hoglet]

IIRC the version history is like this:
- v1.x, SDDOS for a VIA SD-card interface
- v2.x, SDDOS for the AtoMMC interface
- v3.x, SDDOS for the FPGA (upgraded v1.x)

Right?

As far as I understand.

The v2.x branch works with the B800 VIA or B400 SPI interfaces.

The v3.x branch works with the AtoMMC interface (AVR version and PIC version)

The v1.x branch was before my time.

I wouldn't bring FPGA into it, because there are so many variants. What matters is the hardware interface, not whether it is original or FPGA.

Dave

[Prime]

[quote="hoglet"

The v3.x branch works with the AtoMMC interface (AVR version and PIC version)

I wouldn't bring FPGA into it, because there are so many variants. What matters is the hardware interface, not whether it is original or FPGA.
[/quote]

Yes it would be best to have the FPGA emulate either the PIC or AVR hardware...hehehe if your FPGA had enought lines you could emulate PL8 and plug in a real AtoMMC

Cheers.

Phill.

[hoglet]

Hi Dave,

I did find this one.

Kees

The good news is I've re-built SDDOS 3.25 from source using these files, and the binary is the same as the one you have previously distributed.

The bad news is I still get an "SD ERROR 46" when I do a *DCAT, which is similar to what Phil Young got in this thread:
http://www.stardot.org.uk/forums/viewto ... 419#p77496

Except his was an SD ERROR 45 mine is SD ERROR 46.

I think this error comes straight back from the AVR/PIC firmware, and is:
FR_INVALID_NAME

I'll need to do some debugging tomorrow, if I can create enough AVR ROM space in the FPGA to fit both SDDOS and Serial Console.

Dave

[IanS]

ramrom.zip

This doesn't support the RAMROM board with DISKROMEN disconnected (for use with floppy disk controller). Or is there a better way to do it?

[oss003]

I have also update the ramrom.zip file.

You can set the jumpers with software:

Code: Select all

Jumpersettings can be overruled by writing to #BFFE:

RAMBANK:
Bit0: 0 = #7xxx is normal RAM
      1 = #7xxx is mapped to #Axxx ROMbank0

BLKAEN:
Bit1: 0 = #0Axx is normal RAM
      1 = #0Axx is mapped external for diskcontroller

DSKROMEN:
Bit2: 0 = #E000-#EFFF set1, AtoMMC + BRAN
          #F000-#FFFF set1, Kernel patched for BRAN
      1 = #E000-#EFFF set2, Atom DOS
          #F000-#FFFF set2, Kernel original

BBCEN:
Bit3: 0 = Atom mode
      1 = BBC mode

Greetings
Kees

[IanS]

Excellent, Thank You.

[Prime]

Just to point out that bit 2 when it says Atomdos, it really means "a rom on an external card at $E000", this will indeed normally be a dos rom on an external floppy card.

Also bit 2 isn't quite as simple as the other bits, as there is also the dskrom jumper, the actual value is bit 2 xor the jumper. The net affect of this is that bit 2 can be used to invert the jumper whatever it's set to.

Cheers,

Phill.

[IanS]

Just to point out that bit 2 when it says Atomdos, it really means "a rom on an external card at $E000", this will indeed normally be a dos rom on an external floppy card.

Also bit 2 isn't quite as simple as the other bits, as there is also the dskrom jumper, the actual value is bit 2 xor the jumper. The net affect of this is that bit 2 can be used to invert the jumper whatever it's set to.

Good to know. I can take off the wires extending the diskromen link outside the case.

Does the change take effect immediately, or after next break/reset?

[Prime]

It takes place immediately, you might find you need a break under certain circumstances tho, I always tend to hit break, but have not really tested not doing so.......

Cheers.

Phill.

[IanS]

I can't think of a case where changing it on the fly is useful. I always changed the jumper (now ?#bffe) and then pressed break. Just curious if it was latched on break/reset.

[oss003]

I can't think of a case where changing it on the fly is useful. I always changed the jumper (now ?#bffe) and then pressed break. Just curious if it was latched on break/reset.

It's useful for a MMC <-> disk copy program ...

Greetings
Kees

[IanS]

Does such a program exist? For the few files I need to do (the forth "screens") I loaded them all into memory from disc, swapped over to MMC and saved them back out again.

[Prime]

Does such a program exist? For the few files I need to do (the forth "screens") I loaded them all into memory from disc, swapped over to MMC and saved them back out again.

Not at the moment

The other thing that would probably be useful would be an SDDOS disk image <> Floppy transfer program. The two systems should be able to co-exist in memory as the SDDOS IIRC uses the $2000-$27FF as workspace, the ADOS 1770 uses $1000-$17FF. What we really need to do is to design a jump table or similar so that we can have fixed entry points. OK we could just jump to the routines in ROM, but that has the definite disadvantage that as these things are still changing from time to time as bugs are fixed etc the entry points could move

The other option of course would be to talk to the AtoMMC / 1770 / 8271 directly, maybe with an option for changing the IO address of the floppy, as there are two options on the new controller, and IIRC several people patched their Atoms / AtomDOS to use a block in $Bxxx rather than $0A00.

Cheers.

Phill.

[hoglet]

Kees,

I've added the BootLoader and BootLoader Updater sources into github.
https://github.com/hoglet67/AtoMMC2Firm ... its/master

I've also added various binary releases of the Firmware:
https://github.com/hoglet67/AtoMMC2Firm ... 7626ea04df

Dave

[oss003]

Great job Dave, I like the way you solved this problem. Really impressive ....

Greetings
Kees

[oss003]

Ok guys,

software updated to v3.00 in first post.

Greetings
Kees