AtoMMC and random access files

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
Post Reply
User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

AtoMMC and random access files

Post by roland » Fri Oct 03, 2014 10:37 pm

I think this one is for Sir Morris or Kees:

Is it hard to implement random access file support on the AtoMMC?

Or is there another way to read and write a chunk of a file?

Later .... when my new Atom is finished and working fine .... I want to connect a second cpu to my Atom. For file transfers I cannot always load the entire file in Atom memory and then pass it to the second CPU. So I want to read a block of data and transfer that to the second CPU. Random access files are very suitable for this. But they are not supported on AtoMMC.

However, I cannot imagine that SDDOS reads and writes the entire disc image into Atom's memory (because these images are bigger then Atom's ram) so how does that work?

Greetings,
Roland
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: AtoMMC and random access files

Post by hoglet » Sat Oct 04, 2014 7:07 am

There was a little bit of discussion in this thread:
http://www.stardot.org.uk/forums/viewto ... 362#p88362

I'd be interested in this as well, as a few programs in the archive are broken because of the lack of this feature.

Dave

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Sat Oct 04, 2014 9:02 am

I did a little search to FATFS and I found this page: http://elm-chan.org/fsw/ff/00index_e.html In the list of functions there is a seek command:
Description
The f_lseek() function moves the file read/write pointer of an open file. The offset can be specified in only origin from top of the file. When an offset beyond the file size is specified at write mode, the file size is expanded to the specified offset. The file data in the expanded area is undefined because no data is written to the file. This is suitable to pre-allocate a cluster chain quickly, for fast write operation.
That indicates that random access files should be possible if this function is also implemented in the AtoMMC. And I think it is. How else will SDDOS be able to position the data at a specific position in the image file?

The answer is either in the source of SDDOS or in Kees' head :wink:

According to the buffers, I don't mind if they are in the memory area of the Atom or in the PIC/AVR. After all, the area #2000-#27FF is by design reserved for file buffers and we have plenty of unused ram at #800 - #FFF for buffers.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Sat Oct 04, 2014 9:10 am

roland wrote:I did a little search to FATFS and I found this page: http://elm-chan.org/fsw/ff/00index_e.html In the list of functions there is a seek command:
Description
The f_lseek() function moves the file read/write pointer of an open file. The offset can be specified in only origin from top of the file. When an offset beyond the file size is specified at write mode, the file size is expanded to the specified offset. The file data in the expanded area is undefined because no data is written to the file. This is suitable to pre-allocate a cluster chain quickly, for fast write operation.
That indicates that random access files should be possible if this function is also implemented in the AtoMMC. And I think it is. How else will SDDOS be able to position the data at a specific position in the image file?

The answer is either in the source of SDDOS or in Kees' head :wink:

According to the buffers, I don't mind if they are in the memory area of the Atom or in the PIC/AVR. After all, the area #2000-#27FF is by design reserved for file buffers and we have plenty of unused ram at #800 - #FFF for buffers.
Hi guys,

There are some special commands in the AtoMMC rom to read/write a 256 byte sector just like the Atom DOS does. In fact a 512 bytes FAT sector will be read and the correct half (256 bytes) are returned to the Atom.

The problem to implement random access file handling is the free space in the AtoMMC rom. Branquart is in and I don't know if there is enough free space left.

Greetings
Kees

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Sat Oct 04, 2014 9:56 am

The problem to implement random access file handling is the free space in the AtoMMC rom. Branquart is in and I don't know if there is enough free space left.
Then we have a few possibilities:
- Move branquar to #1000 (just like we did in the past)
- Load the random access at a toolbox at #A000 (there is 1 kB free space in SDDOS)
- Replace the COS load and save routines.

IMHO the second option is the best if 1 kB is enough for those routines. A challenge is to initialize the BPUT and BGET vectors to the right rom position. Regarding that, the third option is also not that bad. Having ram at #Fxxx makes it easy to swap the OS if the cassette interface is needed.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
sirmorris
Posts: 776
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: AtoMMC and random access files

Post by sirmorris » Sat Oct 04, 2014 10:57 am

It should certainly be possible to add this.

Do you need true random access or will reading in small sequential chunks work for you? Because you can already do this with some small machine code routines.

Seeking can be achieved right now by opening the file then reading the required number of bytes without transferring them to the atom.

It may be a bit hacky but there's always a way ;)

C

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Sat Oct 04, 2014 11:27 am

That is indeed a tricky way of seeking. I don't know that many programs for the Atom that use true random access files. The only program I have ever written for this was a help system. The keywords were stored in a file with pointers to the text in the help-text-file. By using random access files this worked quite fast.

For the purpose of transferring data to a (future) second processor reading and writing chunks of data will be sufficient, but from the point of compatibility view the true random access is preferred.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Sun Oct 05, 2014 12:07 pm

Hi guys,

AtoMMC is using FatFS and to use Random File Access, we have to use the same command syntax as in Atom DOS:

Code: Select all

FIN -<name>- (function) 
Opens the named file for input and returns its handle, or zero if the attempt is unsuccessful. File handle zero gives input from the keyboard.

FOUT -<name>- (function) 	
Opens the named file for output and returns its handle, or zero if the attempt is unsuccessful. File handle zero gives output to the display.

PUT A,W	
Outputs the four bytes of W to the file whose handle is A.

GET A (function)		
Inputs four bytes from the file whose handle is A, and returns an integer.

BPUT A,B
Outputs the least-significant byte of B to the file whose handle is A.

BGET A ( function) 	
Inputs a byte from the file whose handle is A, and returns the value.

SPUT A,S SP.	
Outputs the string S to the file whose handle is A.

SGET A,S 	
Inputs a string to S from the file whose handle is A.

FPUT A,%F (FP ROM)	
Outputs the 5 bytes of the floating-point variable %F to the file whose handle is A.

FGET A (function, FP ROM)	
Inputs 5 bytes from the file whose handle is A, and returns a floating-point value.

PTR A
Returns the value of, or assigns a value to, the pointer to the next byte for input or output in the file whose handle is A. PTR can be thought of as a special variable -in an expression it returns the current value of the pointer as an integer, and on the left-hand side of an assignment statement it updates the pointer with the result of evaluation of the right-hand side.

EXT A ( function )	
Returns the extent (current length) of the file whose handle is A.

SHUT A	
Closes the file whose handle is A. SHUT O closes all files.
I don't know how much free RAM space is available in the PIC controller otherwise you can define bufferspace in the PIC controller. (Charlie, any idea??)

Greetings
Kees

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Sun Oct 05, 2014 1:51 pm

I have been reading in the AtoMMC source and AtomWare part 2 and I think this is definitively doable. The biggest challenge will be the PTR function which positions the file pointer. This function in not implemented in the AtoMMC rom.

Writing and reading a chunk of data is available. So we can fill a buffer and write those (256) bytes to the SD card. Most of the random access functions are Atom-only such as filling the buffers. It just needs to load and save the data at the right moment.

However, the PTR function is questionable. Charlie's trick of reading and discarding the number of blocks before the requested value is a possible way. But when the PTR goes backwards, then the file has to be closed and reopend so the pointer is reset to 0. And it has low performance, especially on large files.

And how does FAT-FS open a file for writing? Is that in write-only mode or in append mode (so that reading and writing are allowed). That is something to investigate....
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:


User avatar
sirmorris
Posts: 776
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: AtoMMC and random access files

Post by sirmorris » Mon Oct 06, 2014 11:01 am

FATFS can open in any of the usual modes. I think I chose one which would suit all current use cases and stuck with it. It wouldn't be hard to change, perhaps to add a mode selection to the file open command.

Random seek access is also possible. Like Kees implied, it's a simple matter of programming.

C

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

Re: AtoMMC and random access files

Post by hoglet » Tue Oct 14, 2014 8:00 pm

I've been chatting with Kees about how to make forward progress on this.

One bit of information we've been missing is the amount of free RAM used by the PIC Firmware.

To get this, we need to be able to build the PIC firmware.

Here is how I setup a PIC Firmware Development Environment that can do this:

Install Gnu Awk from here:
http://gnuwin32.sourceforge.net/downlinks/gawk.php

In your windows environment variables, add the bin directory of GAWK to your path:
PATH=.......;C:\Program Files (x86)\GnuWin32\bin

Install the Microchip MPC C18 compiler from here:
http://ww1.microchip.com/downloads/en/D ... taller.exe

Get a build of AtoMMC from somewhere that contains the PIC firmware... (ask Kees or Charlie)

Start a new windows command shell

cd to the AtoMMC PICFirmware directory

Edit MB.BAT and set the following variables:
SET BIN=C:\UTILS
SET MCC=C:\Program Files (x86)\Microchip\mplabc18\v3.47

Edit PICFirmware-build2.bat, and add /m"PICFirmware.map" to the mplink.exe command. This will cause a map file to be generated.

Run MB.bat

This will generate the following files:

Code: Select all

PICFirmware.cop
PICFirmware.lst
PICFirmware.hex
PICFirmware.map
The .map file contains the following, which shows RAM usage:

Code: Select all

       .idata_mmc2_core.o      idata   0x000000       data   0x000025
                 .tmpdata      udata   0x000025       data   0x000018
         .udata_c018i_e.o      udata   0x00003d       data   0x00000a
                MATH_DATA      udata   0x000047       data   0x000004
     .udata_picFirmware.o      udata   0x00004b       data   0x000004
        .idata_mmc2_wfn.o      idata   0x00004f       data   0x000004
       .udata_mmc2_core.o      udata   0x000053       data   0x000003
           .udata_mmcio.o      udata   0x000056       data   0x000002
     .idata_picFirmware.o      idata   0x000058       data   0x000001
          .idata___init.o      idata   0x000059       data   0x000000
          .udata___init.o      udata   0x000059       data   0x000000
        .idata_wildcard.o      idata   0x000059       data   0x000000
        .udata_wildcard.o      udata   0x000059       data   0x000000
           .idata_mmcio.o      idata   0x000059       data   0x000000
          .idata_diskio.o      idata   0x000059       data   0x000000
          .udata_diskio.o      udata   0x000059       data   0x000000
              .idata_ff.o      idata   0x000059       data   0x000000
         .idata_c018i_e.o      idata   0x000059       data   0x000000
                windowbuf      udata   0x000100       data   0x000200
                sectorbuf      udata   0x000300       data   0x000200
                globalbuf      udata   0x000500       data   0x000100
        .udata_mmc2_wfn.o      udata   0x000600       data   0x0000e4
              .udata_ff.o      udata   0x0006e4       data   0x00001b
              temp_tblptr      udata   0x0006ff       data   0x000001
                   .stack      udata   0x000e00       data   0x000100
            SFR_UNBANKED0      udata   0x000f80       data   0x000080
So it looks like the region from 700 - E00 is free, which is 1792 bytes.

If each open file needs 512 bytes, that would support 3 open files.

The only thing I'm stuck with is the final step of the build is a Hex to Binary command:
%BIN%\hexdump-d PICFirmware.hex picFirmware-bin\atommc%1.bin %2

I'm struggling to find something that does this... Charlie, any hints?

Dave

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

Re: AtoMMC and random access files

Post by hoglet » Tue Oct 14, 2014 8:14 pm

Atom DOS supports five open files, so it would be nice to match this.

I'm wondering if 256 bytes of memory per open file would be possible.

The PIC firmware would end up having to read each 512 byte sector twice, once for the first half, and once for the second half. But this is unlikely to impact performance that much.

A similar trick would need to be performed on writing (i.e. read, modify, write one half then the other).

There already is a 512 byte sector buffer that could be used for this.

1792 bytes would actually then allow for 7 open files.

Dave

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Tue Oct 14, 2014 8:49 pm

Atom DOS supports five open files, so it would be nice to match this.
You're right, it would be nice but if the overhead of the 256 vs 512 byte buffer is too complex (look who's talking :? ) then you might stick to three buffers. In real life there's almost no program that uses random access files, not to mention five simultaneously open files.

A wild guess is that random files on an Atom cassette were quite useless because the cos doesn't have any buffers at all ( unlike the Elk and BBC) and there is no motor control. That makes this type of file I/O not very useful. And for the Atom DOS there is not much software written. Maybe Infomaster (a Dutch database program) and some disc catalog programs use random files. So don't bother to much about Atom DOS compatibility.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: AtoMMC and random access files

Post by hoglet » Tue Oct 14, 2014 8:56 pm

I agree about the number of open files. Simple is better!

Incidentally, there are a few programs in the archive that are not working because they use random access files commands:
- Acornsoft Business/SALES
- Acornsoft Business/GRAPH
- Atomic Theory and Practice/Animals (Chapter 9)

Dave

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Tue Oct 14, 2014 9:06 pm

The animals program uses only one open file so that will run perfectly :lol:
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 7:21 am

Hi guys,

the option to have 3 open files is ok with me. Can't remember programs that open more than 2 files simultaneously.

A sector length of 512 bytes makes more sense because FATFS works with 512 bytes sectors. There is some support for reading/writing 256 byte sectors. Charlie added these routines for SDDOS just to be compatible with the Atom DOS routines.
I wonder if not using any buffer would have a great impact on the speed? IIRC Roland did write an Atom News article catalog program using Random Access files but you could have a cup of coffee when you want to find an article ;)

We also have to ask Charlie if he sold any AtoMMC interfaces with another PIC controller than the 18F4525. The firmware is for the 18F4520/23 and 25. The xx20 and xx23 have 1536 bytes SRAM and the xx25 has 3968 bytes. Random Access file support will only work on the xx25.

CHARLIE ... are you out there ... :)

Greetings
Kees

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

Re: AtoMMC and random access files

Post by hoglet » Wed Oct 15, 2014 7:30 am

Kees,

Hope you are OK with me moving discussions back onto the forum, so Roland, Charlie, Phill and others can chime in.

I think the most important task is to figure out how the PIC Command interface would need to change to accommodate multiple files.

Here are the commands today:

Code: Select all

// Directory commands
#define CMD_DIR_OPEN		0x00
#define CMD_DIR_READ		0x01
#define CMD_DIR_CWD			0x02

// File commands
#define CMD_FILE_CLOSE		0x10
#define CMD_FILE_OPEN_READ	0x11
#define CMD_FILE_OPEN_IMG	0x12
#define CMD_FILE_OPEN_WRITE	0x13
#define CMD_FILE_DELETE		0x14
#define CMD_FILE_GETINFO	0x15

// Data transfer commands
#define CMD_INIT_READ		0x20
#define CMD_INIT_WRITE		0x21
#define CMD_READ_BYTES		0x22
#define CMD_WRITE_BYTES		0x23

// EXEC_PACKET_REG  command
#define CMD_EXEC_PACKET		0x3F

// SDDOS commands
#define CMD_LOAD_PARAM		0x40
#define CMD_GET_IMG_STATUS	0x41
#define CMD_GET_IMG_NAME	0x42
#define CMD_READ_IMG_SEC	0x43
#define CMD_WRITE_IMG_SEC	0x44
#define CMD_SER_IMG_INFO	0x45
#define CMD_VALID_IMG_NAMES	0x46
#define CMD_IMG_UNMOUNT		0x47

// Miscellaneous utility commands
#define CMD_GET_CARD_TYPE	0x80
#define CMD_GET_PORT_DDR	0xA0
#define CMD_SET_PORT_DDR	0xA1
#define CMD_READ_PORT		0xA2
#define CMD_WRITE_PORT		0xA3
#define CMD_GET_FW_VER		0xE0
#define CMD_GET_BL_VER		0xE1
#define CMD_GET_CFG_BYTE	0xF0
#define CMD_SET_CFG_BYTE	0xF1
#define CMD_READ_AUX		0xFD
#define CMD_GET_HEARTBEAT	0xFE
At the moment, the design supports a single open file (i.e. the PIC Firmware maintains a single 512 byte buffer, plus associated FIL/FILINFO objects.

Adding support for SEEK (f_seek) and TELL (f_tell) commands would pretty much allow the Atom Random Access file commands to be implemented, but only on the one open file.

Code: Select all

#define CMD_FILE_SEEK	0x16
#define CMD_FILE_TELL	0x17
In addition, this open file state would be trashed if any other file command was done (e.g. LOAD)

The other necessary change to the command interface would be somehow being able to specify which file to operate on. This would need to be added to the file (0x1x) and data transfer (0x2x) commands.

File 0 would be the existing "scratch" file buffer, used for load/save etc

Files 1-3 would be the random access files.

So, basically this boils down to somehow feeding a new 2-bit number into the file and transfer commands.

There are a couple of ways I can think of doing this.

1. Use 2 bits of the command ID itself to specify the file.

For the data transfer commands, this might mean:
0x20-0x23 would mean file 0
0x24-0x27 would mean file 1
0x28-0x2B would mean file 2
0x2C-0x2F would mean file 3

For the file commands, it's a slightly messier:
0x10-0x17 would mean file 0
0x30-0x37 would mean file 1
0x50-0x57 would mean file 2
0x70-0x77 would mean file 3

2. Add new random access variants that somehow take an additional filenum param:
0x28-0x2B would be new random access data transfer commands
0x30-0x37 would be new random access file commands

The difficulty here is thinking of how to pass in this additional param.

At the register level, there are only four registers:

Code: Select all

CMD_REG			0x00
LATCH_REG			0x01
READ_DATA_REG		0x02
WRITE_DATA_REG		0x03
And the LATCH_REG is already used as a parameter in one commands - CMD_READ_BYTES - to indicate the number of bytes to read.

We could add a command to set the current filenum, but it seems very inefficient to have to now send two commands.

Anyone have any thoughts on this, or other approaches?

I'm inclined towards (1), as it is both backwards compatible and efficient, but would limit us to a maximum of 3 open files (which I am fine with).

Dave

PhilYoung
Posts: 203
Joined: Sun Jun 12, 2011 4:55 pm
Contact:

Re: AtoMMC and random access files

Post by PhilYoung » Wed Oct 15, 2014 7:40 am

Hi,
oss003 wrote:Hi guys,

the option to have 3 open files is ok with me. Can't remember programs that open more than 2 files simultaneously.
I think 2 would be the minimum useful (so you can open one file, process it and pipe the results to the second file), 3 would be better of course (50% better I suppose).
oss003 wrote:
We also have to ask Charlie if he sold any AtoMMC interfaces with another PIC controller than the 18F4525. The firmware is for the 18F4520/23 and 25. The xx20 and xx23 have 1536 bytes SRAM and the xx25 has 3968 bytes. Random Access file support will only work on the xx25.
Both my AtoMMCs were supplied with the *20 PIC, but Phill supplied the *25 version along with the RAM/ROM board so that SDDOS would be supported. So presumably there will be some *20s out there.

Could the PIC code be published at all ? Obviously that is up to the Authors but might be useful for people to have a look at. People who can follow that code that is, which doesn't include me. Ideally on Hoglet's git repository (or similar) so that we are all reading from the same page.

Cheers,

Phil Young

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 8:19 am

PhilYoung wrote:Could the PIC code be published at all ? Obviously that is up to the Authors but might be useful for people to have a look at. People who can follow that code that is, which doesn't include me. Ideally on Hoglet's git repository (or similar) so that we are all reading from the same page.
That's up to Charlie because he's the creator of the PIC firmware.

Greetings
Kees

PhilYoung
Posts: 203
Joined: Sun Jun 12, 2011 4:55 pm
Contact:

Re: AtoMMC and random access files

Post by PhilYoung » Wed Oct 15, 2014 10:09 am

Hi Kees,
oss003 wrote:
PhilYoung wrote:Could the PIC code be published at all ? Obviously that is up to the Authors but might be useful for people to have a look at. People who can follow that code that is, which doesn't include me. Ideally on Hoglet's git repository (or similar) so that we are all reading from the same page.
That's up to Charlie because he's the creator of the PIC firmware.

Greetings
Kees
Yes, that's quite understood, the author/s should decide what they want to do with their efforts, I wasn't suggesting otherwise,

Cheers,

Phil Young

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Wed Oct 15, 2014 6:10 pm

What about the buffers not in the PIC but in the Atom memory? There is plenty of room. However this will bring the buffer housekeeping to the MMC Rom which is almost full with Branquar added to it. It eliminates the PIC memory-size-problem.

According to the documentation, file 0 is for terminal input/output (write to screen, read from keyboard). I'm not aware of any program that uses that file, but maybe *SPOOL and *EXEC use it. Not sure about that ....

IIRC Roland did write an Atom News article catalog program using Random Access files but you could have a cup of coffee when you want to find an article
Did I? :oops:
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: AtoMMC and random access files

Post by hoglet » Wed Oct 15, 2014 8:05 pm

PhilYoung wrote:Could the PIC code be published at all ? Obviously that is up to the Authors but might be useful for people to have a look at. People who can follow that code that is, which doesn't include me. Ideally on Hoglet's git repository (or similar) so that we are all reading from the same page.
Actually, I just realized there was some discussion about releasing the PIC firmware in the Atom FPGA thread, where both Charlie and Phil were happy to have a version published on github:
http://www.stardot.org.uk/forums/viewto ... are#p88070

Here are some places you can find it:
https://github.com/hoglet67/AtomFpga/tr ... /atommc2fw
https://github.com/hoglet67/Optima/tree ... src/atommc

It's also in the official Atomulator distribution:
http://atomulator.acornatom.co.uk/downl ... illH-S.zip

If we are going to do this random access stuff, I would love to get both the firmware and atommc into github, with as much version history as we can find. Something we have been talking about for a while. Charlie has some old versions of atommc here:
http://www.retrosoftware.co.uk/hg/AtoMMC/

Dave

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 8:35 pm

roland wrote:Did I? :oops:
Yep, Atom Nieuws Item Tracer: http://www.acornatom.nl/atom_nieuws/199 ... 923042.htm

Greetings
Kees

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 8:41 pm

Hi Roland,
roland wrote:According to the documentation, file 0 is for terminal input/output (write to screen, read from keyboard). I'm not aware of any program that uses that file, but maybe *SPOOL and *EXEC use it. Not sure about that ....
A long time ago I did some testing with random file access files by writing an Atom library for CC65. File 0 works, write = screen output en read = keyboard input.

Greetings
Kees

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

Re: AtoMMC and random access files

Post by hoglet » Wed Oct 15, 2014 8:46 pm

oss003 wrote:A long time ago I did some testing with random file access files by writing an Atom library for CC65. File 0 works, write = screen output en read = keyboard input.
If I'm understanding correctly, then this is something that would be handled by AtoMMC, and is not a concern of the PIC Firmware.

Dave

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Wed Oct 15, 2014 8:52 pm

oss003 wrote:
roland wrote:Did I? :oops:
Yep, Atom Nieuws Item Tracer: http://www.acornatom.nl/atom_nieuws/199 ... 923042.htm

Greetings
Kees
O yes, I remember. It was so slow because of the slow disk drives. Or did you drink your coffee in one gulp?
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 8:55 pm

File 0 is handled by the random access file handling in Atom DOS and redirected to screen output and keyboard input.

Greetings
Kees

User avatar
oss003
Posts: 3184
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: AtoMMC and random access files

Post by oss003 » Wed Oct 15, 2014 8:56 pm

roland wrote:O yes, I remember. It was so slow because of the slow disk drives. Or did you drink your coffee in one gulp?
No, didn't have to do that because in those days I could keep my coffee warm by putting it on the power supply .... :lol:

Kees

User avatar
roland
Posts: 3628
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: AtoMMC and random access files

Post by roland » Wed Oct 15, 2014 8:58 pm

hoglet wrote:If I'm understanding correctly, then this is something that would be handled by AtoMMC, and is not a concern of the PIC Firmware.
That is correct. So in the PIC firmware you can use file 0 internally.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

Post Reply