WDC C compiler for use with FUZI.

[tokafondo]

WDC's own C compiler was released full version time ago, for non-commercial projects.

From its documentation...

"The WDC C compiler is a full ANSI standard implementation & math IEEE-754 1985. The compiler is fully validated using the Plum Hall Validation Suite against the ISO/IEC 9899:1999(E). The compiler and library functions are only validated against those listed in the ANSI C standard, except for those listed in the “compiler testing” document that is sent with each release."

"The compiler supports IEEE-754 1985 single and double precision floating point variables and arithmetic. No option is necessary to access the floating point feature. All floating point operations with the exception of assignment are performed by pushing the operands on the stack and calling assembly language routines. These assembly language routines are located in a special floating point library along with the standard mathematical library routines. Please see the library CHAPTER for the names and linking conventions. The floating point library also contains versions of printf and scanf that work with floating point values."

https://www.westerndesigncenter.com/wdc/documentation/816cc.pdf

The problem is that those utilities are only available for Windows OS.

But apart from that, would this software be able from the specs to compile FUZI?

Thanks.

[EtchedPixels]

The current port for 65x02 and 65C816 uses the 8bit modes and also makes some fairly careful choices in order for swapping and task switching to work well. In particular it never uses mvn/mvp in user space, never pushes and restores a bank number, and never assumes the stack and data are in the same segment, or in segment 0 or that banks will not change mid execution.

I would be very surprised therefore if you could use the WDC compiler. and as it's a closed product there's no real way to fix that.

[mrdudz]

Am Mittwoch, 24. März 2021, 17:36:10 CET schrieb EtchedPixels:

The current port for 65x02 and 65C816 uses the 8bit modes and also makes some fairly careful choices in order for swapping and task switching to work wel. In particular it never uses mvn/mvp in user space, never pushes and restores a bank number, and never assumes the stack and data are in the same segment, or in segment 0 or that banks will not change mid execution.

I would be very surprised therefore if you could use the WDC compiler. and as it's a closed product there's no real way to fix that.

While speaking of the 6502 port.... does it currently work? I am playing with the idea of porting it to the C64 with Turbo Chameleon (which is an expansion cartridge that provides 16MB of banked memory and a simple MMU) using cc65 - does that sound realistic? Is there some sort of "howto" that explains what needs to be done to make a port work on a new target?

--

http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net

Man who stands on toilet is high on pot.

[EtchedPixels]

The head of the tree before I merged the ARM and ESP trees was running on my 65C02 and 65C816 RC2014 boards. I've been busy on other more social online stuff due to the covid lockdown so I've not retested it on 65x02 since then.

A lot depends upon how your MMU works. From the manual the TC seems to have the ability to do a lot of nice remapping so that looks fine in fact ideal.

The other big "gotcha" is I/O. A unixlike OS assumes a reasonable sized block based storage that runs at an ok speed. My experience of even the C128 for disk I/O are painful. Floppy can work at good floppy speed - the Cromemco port runs with 1MB 8" floppies acceptably (roughly equivalent to a PC era 1.44MB floppy in terms of speed/performance) but it's not really big enough to be a useful disk size. One of the Z80 ports uses bit banged SPI at about 15Kbytes/second to SD card and that's also bearable. You shouldn't need swap as you've got a ton of memory so maybe it works I don't know.

[piso77]

Am Mittwoch, 24. März 2021, 17:36:10 CET schrieb EtchedPixels:

While speaking of the 6502 port.... does it currently work? I am playing with the idea of porting it to the C64 with Turbo Chameleon (which is an expansion cartridge that provides 16MB of banked memory and a simple MMU) using cc65 - does that sound realistic? Is there some sort of "howto" that explains what needs to be done to make a port work on a new target?

Is that the C= REU? Or a brand new memory expansion?

[mrdudz]

Am Mittwoch, 24. März 2021, 18:00:30 CET schrieb Paolo Pisati:

Is that the C= REU? Or a brand new memory expansion?

It isnt just a memory expansion, it is a multi-function cartridge that has all kind of expansions, a CPU turbo, and can in fact run standalone as a complete C64. see http://wiki.icomp.de/wiki/Chameleon

Am Mittwoch, 24. März 2021, 17:55:37 CET schrieb EtchedPixels:

The head of the tree before I merged the ARM and ESP trees was running on my 65C02 and 65C816 RC2014 boards. I've been busy on other more social online stuff due to the covid lockdown so I've not retested it on 65x02 since then.

A lot depends upon how your MMU works. From the manual the TC seems to have the ability to do a lot of nice remapping so that looks fine in fact ideal.

Simply said, the memory is organised in 4k blocks, of which each can be mapped to any address in the 16MB memory. I am using this extensively for the Firmware, it is quite flexible indeed - so i am convinced it will work fine for an OS :)

The other big "gotcha" is I/O. A unixlike OS assumes a reasonable sized block based storage that runs at an ok speed. My experience of even the C128 for disk I/O are painful. Floppy can work at good floppy speed - the Cromemco port runs with 1MB 8" floppies acceptably (roughly equivalent to a PC era 1.44MB floppy in terms of speed/performance) but it's not really big enough to be a useful disk size. One of the Z80 ports uses bit banged SPI at about 15Kbytes/second to SD card and that's also bearable. You shouldn't need swap as you've got a ton of memory so maybe it works I don't know.

Chameleon also has an interface for SD card in SPI mode (and even hardware support, ie a one byte shift register). For a first initial port i'd just use something like half of the memory for a RAM Disk (as that is probably easier to get running).

There is also an option to connect an CS8900 ethernet interface, which with some luck is already supported by some port as well(?)

So is there some more elaborate info/docs on what needs to be done? I have some experience with porting stuff to another target (FreeRTOS mostly) but a few pointers would certainly help a lot :)

--

http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net

last time I tried the c64-test on a date she fell asleep after just 4 hours of demos. That was when I knew she wasnt right for me. i mean.. falling asleep after just a few hours of c64 demos? We have a word for that stuff on the scene. L A M E. (: <Jucke/G*P>

[piso77]

On Wed, Mar 24, 2021 at 6:11 PM Bob Andrews @.***> wrote:

Am Mittwoch, 24. März 2021, 18:00:30 CET schrieb Paolo Pisati:

Is that the C= REU? Or a brand new memory expansion?

It isnt just a memory expansion, it is a multi-function cartridge that has all kind of expansions, a CPU turbo, and can in fact run standalone as a complete C64. see http://wiki.icomp.de/wiki/Chameleon

I know what the TC is, i've an U2+ in back order... i was just wondering if they recreated the original REU, or if they reinvented their own memory expansion.

[mrdudz]

Am Mittwoch, 24. März 2021, 18:19:43 CET schrieb Paolo Pisati:

I know what the TC is, i've an U2+ in back order... i was just wondering if they recreated the original REU, or if they reinvented their own memory expansion.

Its all of that, it can emulate a 16MB "REU", a 4MB "georam", and you can access the entire on board memory (32MB) via a custom MMU - which for new applications (that can rely on the CPU-turbo being present) is the fastest and most flexible option.

--

http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net

Insisting on perfect safety is for people who don't have the balls to live in the real world.

[piso77]

Custom MMU is the word i was looking for... yep, the manual says it's a custom piece of hw made to map any 4K page into the 6510 space at any address.

Too bad the port would only work on TC hw...

On Wed, Mar 24, 2021 at 6:27 PM Bob Andrews @.***> wrote:

Am Mittwoch, 24. März 2021, 18:19:43 CET schrieb Paolo Pisati:

I know what the TC is, i've an U2+ in back order... i was just wondering if they recreated the original REU, or if they reinvented their own memory expansion.

Its all of that, it can emulate a 16MB "REU", a 4MB "georam", and you can access the entire on board memory (32MB) via a custom MMU - which for new applications (that can rely on the CPU-turbo being present) is the fastest and most flexible option.

--

http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net

Insisting on perfect safety is for people who don't have the balls to live in the real world.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe .

-- bye, p.

[mrdudz]

Am Mittwoch, 24. März 2021, 18:34:39 CET schrieb Paolo Pisati:

Custom MMU is the word i was looking for... yep, the manual says it's a custom piece of hw made to map any 4K page into the 6510 space at any address.

Too bad the port would only work on TC hw...

Well, once it does, "we" could always look at how well it can work with eg just a REU - however, i dont have high hopes for that being practical - you'd still need reasonable fast I/O (IEC devices are really slow. and by that i mean really really slow) and REU generally isnt a good solution for "banked" memory either (you'll have to swap banks via DMA at two cycle per byte speed, which again makes it kindof slow and unusable for something like task switching). The 1541U2 provides some "direct" mechanisms to access the SD card, so perhaps that is an option (but then, this would be 1541U2 specific).

Anyway, the question(s) still stand :)

--

http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net

IBM: It may be slow, but it's hard to use.

[EtchedPixels]

I would start by verifying you can build the 65C02 port for RC2014 and run it on the emulator. At that point you can trust the tools hopefully.

Next step is some kind of output routine so you can debug the early boot up.

For the main parts I would take a look in the docs directory and at rc2014-6502. In particular the memory management ought to be close. The rc2014 setup is 4 16K banks rather than 16 x 4K banks so you can initially probably even copy the layout then adjust it to a smaller common space.

You don't need interrupts or disk I/O until you get to the point the console wants to mount a root file system, at which point you need input and disk I/O. If your SD is fairly generic then you only need to provide a few routines for the SD layer to do the rest.

[mrdudz]

OK cool, yeah SD is fairly generic, console i/o is easy enough. i will have a look :)

[mrdudz]

I have managed to compile something (with some roadbumps, ie cc65 things i had to work around) - however, i cant figure out how to make it boot in rc2014. Please give some hints :)

what i tried:

$ ./rc2014/makedisk 1 my.cf
$ dd if=fuzix/Kernel/fuzix.img of=my.cf bs=512 seek=2 conv=notrunc
$ ./rc2014/rc2014-6502 -r RC2014-ROM/6502/rom -i my.cf
rc2014: no UART selected, defaulting to 16550A
RC2014 6502 512K RAM/ROM 0.09

[01 01 01 00 00 40 40]Loading...
[00 01 01 00 00 40 40][00 01 00 00 00 40 58]000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000not bootable

that looks like "almost there" :) but not quite

[EtchedPixels]

You need a boot block on the virtual disk not just a file system. The boot ROM git also contains the loader.

I should move that to the Fuzix tree and document it!

[mrdudz]

Please do - this rc2014 target is totally alien for me - so this is kind of a showstopper right now :)

[EtchedPixels]

Updated

[mrdudz]

ok, another try. almost there

$ ./rc2014/makedisk 1 my.cf
$ dd if=./RC2014-ROM/6502/loader of=my.cf bs=512 seek=2 conv=notrunc
$ dd if=./fuzix/Kernel/platform-rc2014-6502/fuzix.img of=my.cf bs=512 seek=3 conv=notrunc
$ ./rc2014/rc2014-6502 -r RC2014-ROM/6502/rom -i my.cf

It appears to load the kernel, but then fails at mounting the root filesystem. It would be really helpful to have all the required commands to produce a working image in that documentation :) Last time i manually required to put bootblocks and partition tables and filesystems on a disk manually was probably 25 years ago :)

[EtchedPixels]

Make a blank disk (not a makedisk image) fdisk it - add a partition of 32MB dd the loader taking care not to wipe the partition table dd the kernel

Now you can put the file system at block 2048 of the image, and then dd the lot to block 2 onwards of my.cf

[mrdudz]

Make a blank disk (not a makedisk image) fdisk it - add a partition of 32MB dd the loader taking care not to wipe the partition table dd the kernel

Now you can put the file system at block 2048 of the image, and then dd the lot to block 2 onwards of my.cf

No offence - but this doesn't really help me. No matter what i do, i always get some message about it not being able to boot - so i must be doing it wrong, or missing something, or whatever else that apparently is totally obvious to you.

As said, it would be really helpful to have the actual commands needed to produce that image. I'll have to give up at this point, i have no idea how to even debug any of this :(