You can count on the disk driver package getting two dedicated bytes in the zero page. Currently, it is using 8 and 9, but that is subject to change.

The Y register is perfect for dealing with a 256 byte sector, isn't it...

I think Page Zero usage for pretty much any code should be clearly defined with the ability to be moved to a different location. Yes, it will generally require that the code be re-assembled, but it also allows the flexibility to be ported into various existing systems. My current BIOS uses the top 32 locations in Page Zero, the Monitor uses another 48 bytes just below it, so there is free space from $00 - $AF. I have a CMOS version of EhBasic working with this, and it's pretty heavy on Page Zero usage from $00 - $85. This is less than the original code, but it's also contiguous space. In my implementation (of FLEX), I would declare/reserve some Page Zero space for it, perhaps 16 (or more) bytes, located just below the Monitor declared space.

Then again, I might end up allocating additional (Page Zero) space for the BIOS extensions to support the IDE port and and the RTC chip, which is a DS1511Y. I'll know more once I start writing the code to support these additional I/O devices.

The Y register works great for the 256 byte sector data transfer... albeit this is somewhat less advantageous with an IDE device used for storage, as sector sizes are fixed at 512-bytes. I'm thinking that a delayed sector write routine could help overall performance, as in many cases, multiple sectors are written sequentially. This could be a possible performance plus during a multiple sector write (or read), as FLEX may want to access multiple contiguous sectors. Then again, this should be managed transparently to FLEX by the Disk Driver Routines, so it would be at a lower level of code that is not FLEX.

I think some of this becomes enhancements to the original version of FLEX, but as newer implementations of 65(C)02 systems can easily have full memory addressing and some better I/O devices, it sorta makes sense to add these in. As FLEX for the 6502 will be a new OS, maintaining 100% backward compatibility doesn't really come into play (at least in my mind).

_________________
Regards, KM
https://github.com/floobydust

This is where we are going to have a problem.

The FLEX philosophy on the 680x is that the zero page is just an optimization for faster and smaller code. Nothing more and nothing less. Because system software deals with slow storage devices and even slower human operators, it does not need and therefore does not use the zero page. The entirety of the zero page is the domain of application programs to use as they see fit.

Monitor ROMs use a small amount of scratchpad RAM located somewhere in high memory. FLEX itself puts its variables within the system image.

FLEX utilities run in a special area within the system image called the Utility Program Space. They also leave the zero page alone.

The 6502 zero page is special. Some addressing modes only work with zero page locations.

System software could conceivably save the contents of the locations it uses for address indirection to be restored afterward. I have not taken that step and simply reserve a few locations.

Some programs such as the assembler, text editor, the Space Voyage game and any BASIC interpreters I may choose to implement will not be able to operate without stomping on your data.



The code like this will handle 512 bytes efficiently:

Well, I don't see this as the start of having a problem.... perhaps just a different view when writing code for the 6502. For the most part, I tend to keep page zero usage low, but I find it much more useful for efficient coding. When you only have 64KB total space, saving some of it can make the difference in getting things done versus not. I'd also note that most user programs spend a lot of time waiting for user input as well, so reserving page zero exclusively for that one doesn't really fly for me. I also leverage the CMOS enhancements quite a bit... additional opcodes and addressing modes, etc. They're quite useful and the bit instructions which are unique to page zero are very useful for setting, clearing, testing and branching on them. One byte in page zero can yield 8 separate flags for other bits of code.

In any case, I don't see programs like editors, assemblers, etc. requiring all of page zero to function, unless they are simply written to allocate all of it for the sake of doing so. Again, you're specifically referencing the 6800 for making these decisions. I think programming the 65C02 should take a somewhat different path, but again.... you're doing the port of FLEX, so all of the decisions and choices are yours to make. I'd also note that Commodore's Macro Assembler package for the C64 worked pretty well... assembler, editor and linker... and didn't require that much page zero usage.... as there wasn't that much left.

As for my IDE/RTC adapter, the BIOS will be using some additional page zero locations. Transferring data from the CF-Card will not be slow. Even in PIO Mode 1, it's rated at 1.6MB/Second. Even an 8MHz 65C02 will not be able to match that rate when reading or writing a single sector. I guess it would be interesting to know how much page zero you're planning to require for the additional utilities, being the assembler, editor, Basic interpreter, etc. Proposed Stack usage could be another interesting bit to know.

All the best,

_________________
Regards, KM
https://github.com/floobydust

Now is the time to hash this out - before any software is released and documentation is published.

I go back to your earlier statements:



and



So you are proposing:

???..$9F IDE/RTC
$A0..$AF FLEX
$B0..$DF Monitor
$E0..$FF BIOS

I surely hope you are not intending to make EhBasic resident in ROM as that leaves almost nothing in the zero page for application programs.

My belief is that 680x programs used the zero page primarily not for the maybe 10% increase in speed, but for the perhaps 20% decrease in code size. This was at a time when the recommended minimum memory was 12K of user RAM starting at address 0 plus 8K at a higher address for the operating system.

I am all but sure about loading parts or all of FLEX to $200..$1FFF in the systems which allow it with the rest at the top end of user RAM. User RAM starts at somewhere around $2C00 on all systems. The practical minimum is 16K of free user RAM needed to edit and assemble non-trivial programs.

I believe 6502 programs will still need the smaller code advantage of using the zero page for variables due to the fact that 6502 machine code is not as dense as 680x code.



Stack usage is still a big unknown at this point. The assembler and the editor do not appear to use that much. The BASIC interpreters, I have no idea yet. As mentioned before, 680x programs are free to place the stack anywhere and it is then not limited to 128 or 256 bytes.

Okay, so let me try and clarify where I am on the C02 Pocket SBC. The current version uses a NXP SCC2691 single channel UART. The next version will use a dual channel UART (SC28L92) but currently no target date to get this done. In any case, it will require a small additional amount of page zero space and RAM to manage the second serial port.

The way I allocate memory for the SBC is fairly simple:

32KB RAM addressed from $0000 - $7FFF:

$0000 - $00FF - Page Zero... cover this in more detail below
$0100 - $01FF - Processor Stack - non movable... my current BIOS and Monitor can use upwards of 18-24 bytes
$0200 - $02FF - Console UART buffer, 128 bytes for send, 128 bytes for receive
$0300 - $03FF - Software vectors, soft HW config values, buffer and working space for many things... Xmodem-CRC, S-Record, etc.
$0400 - $07FF - Reserved for expansion. Some of $0400 is used for Enhanced Basic, but only when active.

$0800 - $7FFF - User RAM, which is 30KB.

32KB EEPROM addressed from $8000 - $FFFF:

$8000 - $AFFF - Currently open
$B000 - $D78C - EnHanced Basic
$E000 - $F7FF - C02Monitor - 6KB allocated... about 1KB free now, but will be used in the next version
$F800 - $FDFF - C02BIOS - 1.5KB a bit over 0.5KB currently used
$FE00 - $FE9F - I/O usage, 5- selects of 32-bytes wide each
$FEA0 - $FEFF - C02BIOS - vector and hardware config data for initialization - most copied to $0300.
$FF00 - $FFFF - C02BIOS - includes JMP table at $FF00

A couple of notes:
1- EnHanced Basic only uses Page Zero space when it's invoked from the Monitor. A cold start of EhBasic will init it's page zero usage. If you don't need to be actively running EhBasic, then all of page zero from $0000 - $0085 is free.
2- If one of the BASIC interpreters from the FLEX system is a better fit, then it make perfect sense to replace EhBasic.
3- Without EhBasic, EEPROM usage is only 8KB, so there's 24KB available for FLEX and perhaps one or two additional utility programs.
4- $0400 - $07FF are used by the NMI Panic routine to hold a copy of $0000 - $03FF, but that's only for a crash scenario. This could easily be moved elsewhere as it's a rare occurrence.

Current Page Zero usage:

As noted earlier, BIOS uses the top 32 bytes, but there are two free bytes in that space. Monitor uses 48 bytes, with one spare byte there. I'm proposing increasing BIOS by roughly 16 bytes to accommodate the RTC/IDE adapter and the future second UART port. The Monitor might increase a bit, but not planning on it for the remaining functions planned.

So, my future planned page zero usage for all BIOS and Monitor usage would be from $00A0 - $00FF, or 96 bytes total. This leaves 160 bytes of Page Zero free for FLEX and other applications. Available Stack space should be pretty high, I'd suspect around 224 bytes.

Again, my plans are to have FLEX in EEPROM, so that also implies all variables would need to be in RAM. I'm guessing others might have a different view of how to organize memory between RAM, ROM and I/O. I could also change the memory map around... looking to increase RAM to 48KB or 56KB and limit ROM to 16KB or 8KB.

As you're doing the porting of FLEX, have you looked at declaring a default or recommended memory map for using FLEX on the 6502?

_________________
Regards, KM
https://github.com/floobydust

It does feel to me that for the 6502, an OS has an additional job of managing zero page allocation. It's normal enough for an OS to pass to an application a low base and a high limit for RAM usage. (In the world of 6502, where position-independent code isn't natural, it helps for the low base to be a constant. Otherwise one might need a relocating loader. If there's more than one application resident, something must be done!)

So, I would perhaps also expect to see a base and limit for zero page. And, again, it's not so natural for an application to be built so it can adapt zero page usage, so a fixed base and an adequately high limit would help. Of course, the less zero page the OS uses for itself, the more is left for an application. (And, again, if more than one application can be resident, there's a need to handle that, maybe by swapping zero page content on task switching.)

From viewtopic.php?p=75654#p75654



I am now leaning strongly toward adopting something like:

$0000..$00FF - Zero page, usage TBD
$0100..$01FF - Stack
$0200..$1FFF - portion of FLEX as needed and permitted by the individual platform
$2000..$22FF - FLEX entry points, variables, line buffer and printer driver
$2300..$243F - System File Control Block
$2440..$2AFF - FLEX Utility Command Space
$2B00..MEMEND - User memory

Somewhere above that is the remaining portion of FLEX as needed by the individual platform



The FLEX BASIC interpreters are integrated with the OS to provide full LOAD, SAVE, OPEN, CLOSE, INPUT and PRINT functionality with files on disk. Also, you can use EXEC to run a FLEX utility program from within BASIC, FLEX to exit to FLEX and EXIT to exit to the system monitor.

http://www.flexusergroup.com/flexusergr ... sic_um.pdf

You will have to implement those in EhBasic if you need them.

FLEX "memory management" on the 680x was extremely simple but surprisingly effective.

Most system utilities loaded and ran in a 1.5 K hole in the OS image. All other programs were free to utilize user RAM as they wished.

The MEMEND system variable indicated the last byte of usable user RAM.

FLEX did absolutely nothing to enforce anything.

The only thing I wished for was support for disjoint blocks of RAM. The I/O space on the 6800 started at $8000 due to the original MIKBUG definition. Other than the 8 K from $A000 to $BFFF where FLEX resides, there was no standard for using additional high RAM.




Perhaps the best which can be done is to recommend something like:

$00.$01 - reserved for 6510 ports

$EC..$EF - reserved for system monitor
$F0..$FF - reserved for FLEX

Your platform may impose further restrictions.

We recommend that programs limit zero page usage to $02..$8F for maximum compatibility.

The proposed memory usage for FLEX is interesting... the numbers add up to 10.25KB. You then have Page Zero and the CPU Stack just below that, for a total of 10.75KB allocated at the low end of the memory map. This could work for some systems better than others, but it depends on how much upper ROM is used and where the I/O is configured in the overall memory map.

Perhaps a slightly different approach might be worth considering:

The first consideration is to make the core of FLEX (likely around 6KB) to be placed in ROM (or a bootable image). The address in ROM should be flexible, but contiguous and perhaps allocate 8KB of available space. Alternately, allocate another 4KB-8KB for FLEX utilities or a ROM based BASIC version. Updating the ROM contents is still a simple process... either reprogram the ROM (or EEPROM) or possibly reprogram it insitu for EEPROM systems. (My current SBC and Monitor can reprogram insitu.)

The second consideration is to allow the required RAM usage of FLEX to be user defined. This sorta depends on how you're planning to make the code available. If you're planning on making source available (much preferred), it should be fairly easy to edit a configuration file, then re-assemble, link and burn a new ROM or create an updated disk image for booting. If not (making source available), I think it will be more difficult to integrate into an existing system.

As of now, I've completed the hardware design and PCB layout for my RTC/CF-Card adapter. I should have PCBs by EOD Monday next week. I have everything to build one up initially, do some testing, then start writing a BIOS to support it. As Compact Flash (when used in true IDE mode) has 512-byte sectors (or blocks in LBA mode), all reads and writes are done in 512-byte sizes. This pretty much dictates that you need a minimum of one 512-byte memory buffer to hold a single sector (or block). As FLEX accesses at a sector level only (at 256 bytes/sector), a simple translation layer would be appropriate and allow FLEX to use it's own buffers and such.

If all goes well, my SBC will have allocated a minimum of 2KB of RAM from $0000 - $07FF and hopefully no more than 8KB of ROM for the Monitor and BIOS located from $E000 - $FFFF. My goal is to have a BIOS translation layer in ROM to interface to FLEX.

If FLEX can be configured to allocate about 4KB or RAM for usage at the low end, then have another 8KB of ROM space allocated, that could leave a reasonable amount of RAM for user defined apps. In a 32KB RAM system (which I think is pretty common) that could yield a solid 24KB-26KB of user RAM. It would also leave another 8KB-16KB of ROM for additional FLEX utilities and/or extensions.

My next SBC will have two serial ports (NXP SC28L92 DUART) and I'll likely increase the lower RAM usage upwards of 4KB for additional buffers and such. If FLEX can be configured to allocate 4KB of RAM (used as needed) as well as some (configurable) Page Zero space, then the first 8KB of RAM is allocated, so user RAM space starts at $2000 to MEMEND. ROM (EEPROM) would be allocated from the top down and consume a minimum of 16KB for BIOS, Monitor and the core of FLEX.

Of course, this is all wishful thinking on my part, but I thought I'd throw it out here.

_________________
Regards, KM
https://github.com/floobydust

I'm a bit surprised at the idea of FLEX coming in two chunks, or of it providing a modest size hole for utilities:
> FLEX utilities run in a special area within the system image called the Utility Program Space

Is the idea that utilities are built to a fixed address, and can co-reside with the user's application?

I imagine FLEX is built with the idea that code is position-independent, but the 6502 doesn't make that so easy, so it might be advantageous to offer a memory map with a very constant start address for the application area. If there's a platform-specific part of FLEX to be loaded in too, perhaps that can go at the top of user RAM, so it being various sizes on various platforms doesn't affect the start address.

The proposed map is the result of much discussion and compromise. A 6809 style of system at $C000 to $DFFF precludes OSI hardware. Putting the system at $8000 to $9FFF deprives a Corsham system of 16K of address space.

Hence the idea for splitting the public and private parts of the system. The public part was originally placed at $200, but moved to $2000 to accommodate a KIM-1 with the Corsham SD Card interface. Parts of the private parts of the system can be put between $200 and $2000 on individual platforms as allowable to free up upper RAM.



FLEX for the 680x was provided in a single binary file called FLEX.COR to which the disk and console drivers are appended to make a bootable image.

My intent is to provide similar files for common configurations on the 6502. For those who need to change it, a single source file can be modified to build the customized system from source code.

Much of that is historic. Motorola's Mikbug provided the initial memory layout:

$8004 - PIA port bit banged for a serial interface
$A000 - 128 bytes of "scratchpad" RAM for Mikbug
$E000 - Monitor ROM
$FFFx - System vectors

The original operating system (FDOS) on SWTPC computers was located in low memory.

The first version of FLEX for 5 1/4" drives was called Mini FLEX. It loaded at $7000 to $7FFF. It only supported single density disks with 128 bytes per sector.

The next version, popularly called FLEX 2, added support for double density media. The sector size was increased to 256 bytes. The system no longer fit in 4K of RAM. A decision was made to place it above the I/O space; the 128 bytes of scratch RAM at $A000 was replaced with 8K spanning up to $BFFF. The Utility Command Space was increased from 320 bytes in Mini FLEX to 1.5 K.

I do not know whether it was a design decision to run utility programs in a separate area or if it was to take advantage of otherwise wasted space. The ability to run utility programs from within the text editor or BASIC interpreter proved to be a useful feature later.



I am going to insist that the utilities and programs load at the same addresses on all platforms. Requiring versions at different locations for individual platforms is for the birds.

It's certainly an interesting problem of fitting to so many shapes. As you say, rebuilding some parts, some times, from source, allows for some degree of flexibility.

It feels to me that the most important variable is where RAM is to be found - presuming FLEX is to be loaded into RAM. And a part of that is whether RAM is contiguous. As to the rest of the address space, it doesn't matter too much whether it's ROM, I/O, empty, or an image of something else.

Perhaps you could list your targets and briefly tabulate their complement of RAM, in their various minimal, expanded, and maximal configurations?

Although you'll very likely not have Acorn's systems in your list, here's a sketch:

In the land of Acorn's BBC Micro, RAM runs from 0000 to 3FFF in the never-seen 16k variant, or from 0000 to 7FFF in the always-seen 32k variant. In both cases the uppermost part is used for video, and the amount used varies according to the video mode. In the Master model, RAM runs to 7FFF in any case, and to BFFF for this purpose. In a Second Processor, RAM runs up to F800.

In the land of Acorn's Atom, there's more of a patchwork of RAM. But this is relatively rarely seen, interesting though it is to those who own one.

I would agree that attempting to fit (FLEX) into a large array of systems can be a time-consuming task... and from what I can tell, doing the port is more of a "labor of love" than anything else. One of the main problems with 6502 systems is the lack of consistency in memory maps and I/O (both types and locations). In addition to the large number of vintage machines that used the 6502, you also have the endless array of hobbyist machines that have been cobbled together over the decades.

I know I'm being a bit selfish here... as I want to be able to load the core of FLEX into ROM and declare as much RAM as required to allow it to work efficiently. But..... being able to locate in ROM and RAM needs to configurable. My C02 Pocket SBC is about as simple as it gets. It's also very efficient on I/O space, 5- I/O selects that are 32 bytes wide each located at $FE00. All of the code I've written to date uses ROM (EEPROM) from the top down and uses RAM from the bottom up. The idea being to allow as much free contiguous memory in the middle as possible.

If need be, I could piggyback a second 32KB RAM to the board and re-program the ATF22V10 glue chip to configure more RAM and reduce the available EEPROM... but I hate doing hacks on the board. I'm leaning towards having increased RAM on the next SBC which would provide the ability to slide the point where RAM and EEPROM meet (from $8000 upwards). As it stands now, I have about 30KB of available RAM (contiguous) and 24KB of available EEPROM (sans EhBasic).

If I can get FLEX running on this system (with the RTC/CF-Card adapter), it's possible it could be more easily adapted to what many folks out here are building up for themselves. This of course, remains to be seen over time. In any case, I'm happy to try and get this running, once the FLEX code is completed and available. And of course, thanks to BillG for entertaining all of this and working on the port.

_________________
Regards, KM
https://github.com/floobydust