C/80 and VirtualHDOS oddity

[smb...@gmail.com]

I started playing with C/80 for the very first time. Have a look at my Makefile and I will explain:

hdos/hello.abs: devenv/hello.c
        mkdir -p hdos
        vhdos C HELLO
        cp devenv/clibrary.orig devenv/clibrary.asm
        dd if=/dev/zero of=devenv/hello.asm bs=256 count=2 oflag=append conv=notrunc
        dd if=/dev/zero of=devenv/clibrary.asm bs=256 count=2 oflag=append conv=notrunc
        vhdos AS HELLO
        cp devenv/hello.abs hdos/

The oddity is the two `dd` commands that I had to add. Without them, AS would read the some portion of the tale of the assembly file multiple times, generating errors as it saw things defined twice. This is despite the files (clibrary.asm) already being padded out to a multiple of 256 bytes using NULL characters. On another file I'm building I had to add three 256 byte NULL blocks to the end of a file to get it to work.

I'm assuming this wasn't a problem with C/80 "back in the day", so I'm speculating maybe it's an emulator problem now. My workaround works fine, but I thought I'd mention it as a potential bug.

Scott

[Douglas Miller]

I'm not sure if anyone has tried using C/80 and the default AS.ABS, but what you're doing here looks strange. At the very least, you may need to use PIP to combine the files instead of Linux utils. I'll take a peek at the C/80 manual to see what it says about this procedure.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/11065210-7c9e-48d8-a3e0-9ec261a038d0n%40googlegroups.com.

[Joseph Travis]

I'm guessing the emulator is for HDOS 2.0 as the 'C' and 'AS' commands won't work as you would expect for HDOS 3.02.  'C' is an alias for CAT and 'AS' is an illegal command.

Joe

--

[smb...@gmail.com]

I'm not combining the two assembly files -- I'm sticking 512 nulls onto the end of each one.

Scott

[Douglas Miller]

Perhaps it is something to do with AS.ABS, which I haven't analyzed to see what HDOS calls it makes. I certainly haven't had any problem using C/80 with M80 and L80. I know AS.ABS is pretty crude, even Walt seemed to advise against using it.

But, I don't understand what you're using to build HELLO.ABS, and where clibrary.asm comes into things. I guess I need to read up on how AS.ABS is supposed to be used.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a88c9cfa-ad66-45a3-a632-8ba98e9b5e4cn%40googlegroups.com.

[smb...@gmail.com]

I followed the instructions for C/80 which said to run:

   C HELLO

   AS HELLO

When C/80 compiles HELLO.C, it inserts "XTEXT SY0:CLIBRARY.ASM" into the assembly output. That's how CLIBRARY.ASM ends up incorporated into the eventual binary.

I did wonder if running M80 and L80 would be better, as AS seems pretty crude in how it's handling (or maybe it's more appropriate to say, _not_ handling...) linking. These H8 tools are all brand new to me, so I'm happy to choose whatever is known to work best.

Scott

[Glenn Roberts]

The AS approach can only build a single monolithic C file and is (in my opinion) only for beginners. Thats why the CLIBRARY.ASM file has to be included and reassembled every time. If you’ll be doing any serious work with C I recommend using CCCONFIG to set it up for M80/L80. Also as Joe points out, rename it to CC.ABS to avoid conflict with Super SYSMOD’s shortcut commands

Sent from my iPad

On May 17, 2023, at 11:13 PM, smb...@gmail.com <smb...@gmail.com> wrote:

I followed the instructions for C/80 which said to run:

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cdc3a71b-87fa-48c3-a60d-12908d5f284en%40googlegroups.com.

[smb...@gmail.com]

I don't think there's any problem with C.ABS itself. It runs and it produces valid output. The problems are entirely with AS, which seems to be reading past the end of the file and/or duplicating the last block(s) in the file. It does this even on CLIBRARY.ASM, which comes right off the floppy. I still wonder if this is an artifact of emulation --  files are typically padded with NULLs out to a full block size, but I don't know how the emulator emulates this. It's possible the emulator is exposing sloppy implementation or error checking in AS.

If I stick with C80, then I'll switch from AS to M80/L80. However, I might also look into Aztec C as C80 feels very limiting.

Scott

[Douglas Miller]

There's probably something I can tweak in the vhdos emulator. I just need to look at what AS.ABS is doing and adjust.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cb1e6c90-d68c-4c9c-b6e8-64ee55c8861dn%40googlegroups.com.

[Glenn Roberts]

I tried Aztec and didn't see any compelling reason to switch but I'm an admittedly biased data point. Also not sure but maybe the Aztec c we have is incomplete? Seen to recall some missing components? Can't recall. I probably posted a message here at the time....

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cb1e6c90-d68c-4c9c-b6e8-64ee55c8861dn%40googlegroups.com.

[Glenn Roberts]

Scott: curious what you find limiting about C/80. Most of the Software Toolworks products were written with it. I find it to be a very nice tool for coding on the H8. All my Vinculum software (for USB/VDIP) was written with it…

If I can help let me know. 

- Glenn

Sent from my iPad

On May 18, 2023, at 12:41 PM, Glenn Roberts <glenn.f...@gmail.com> wrote:



[smb...@gmail.com]

The last thing I ran into was it told me I had run out of Macro Space... Maybe there's a way to increase that?

I had some trouble with "unsigned int", but upon reflection maybe it just wants me to call them "unsigned" instead of "unsigned int". It also either doesn't support typedefs, or there was something it found malformed about my typedefs.

Basically I was going to try Aztec this weekend, and see if it complained about fewer things. Choose whichever compiler will allow me to do the least amount of work.

Scott

[Douglas Miller]

cconfig allows you to adjust various parameters, specifically allocate space for things like macros. you'll need to adjust those.

typedef is not supported.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f095930e-bfed-4b7b-a081-4fd8616eb5e1n%40googlegroups.com.

[Les Bird]

And for the record, I was able to build Hello.c using C.ABS and AS.ABS without any issues on a floppy system on a real H8 so I'm guessing it is an emulation issue.

Les

[Glenn Roberts]

I’m in New England but can send info on how I’ve got my various buffer sizes set when I get home. I do minimize loading stuff that will suck up RAM since the compiler will need as much as you can spare. It is K&R C which I happen to like. Pretty full implementation but no typedefs.

If you prefer an ANSI implementation or more modern development environment you could look at a cross development tool like z88dk. I guess I’m silly or stubborn and enjoy doing the builds on my actual H8. 

Please let us know how things go if you try Aztec…

Sent from my iPad

On May 18, 2023, at 5:17 PM, smb...@gmail.com <smb...@gmail.com> wrote:

The last thing I ran into was it told me I had run out of Macro Space... Maybe there's a way to increase that?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f095930e-bfed-4b7b-a081-4fd8616eb5e1n%40googlegroups.com.

[Glenn Roberts]

I agree the issue is with the emulator.

Doug: HDOS doesn’t have an EOF character for ASCII files, it just null pads the last sector. Don’t know if that’s a clue… as I recall the directory entry says how many sectors to use in the last cluster of the file? 

Sent from my iPad

On May 18, 2023, at 8:15 PM, Les Bird <lesb...@gmail.com> wrote:

And for the record, I was able to build Hello.c using C.ABS and AS.ABS without any issues on a floppy system on a real H8 so I'm guessing it is an emulation issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fd230024-2330-4a8c-abde-f52e7736cf11n%40googlegroups.com.

[Douglas Miller]

The file is being correctly created, NUL-padded on the last sector. Keep in mond, this all works with M80/L80. As far as I can tell, AS.ABS is doing a simple .READ syscall, check for carry, and then checking for EOF before declaring an error. So far, haven't found anything wrong, but will need to do some tracing. I might try to reproduce with a smaller example to see if I can reduce the amount of trace output. I suspect it is some corner-case where a syscall is not exactly what AS.ABS expects, but other HDOS utils don't care or aren't perturbing things the same way.

It's looking like AS is loading (XTEXT) CLIBRARY.ASM twice, although I can't be certain because I can't get a decent listing file out of AS. Just to make things weirder, AS uses straight octal in the listings, instead of split-octal.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/F79DAA6D-85B2-40DD-AC1C-CE4C2BE54886%40gmail.com.

[Joseph Travis]

To get AS to generate a listing file, use:  AS file,file=file     The addresses shown in the listing are split octal.

AS is compatible with HDOS ASM however, there are certain pseudo ops like SPACE and report them as errors but the generated code is unaffected.  

I personally like that it zero fills the unused portion of a sector unlike HDOS ASM which uses whatever is in the buffer at that time.  I've written a couple utilities I call SLICE and SPLICE which I used for creating ROM images, both of which fill with FF instead of zero.  I can make them and the source code available if you think they can be of use to you.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fdd9c86d-d814-87e2-9b7d-461123dc27d6%40gmail.com.

[Douglas Miller]

I've got a pretty good idea now of what is happening, but don't see anything wrong with what the emulator is returning.

AS.ABS is reading files using a 1K buffer, doing 1K block reads (BC=0400H on calling .READ). It just happens that  the final block read of clibrary.asm fills only 3 sectors of the buffer, leaving the last sector with the contents of the previous block read (the offending duplicate code). But I can't see any reason that AS should think that was valid data. The return values from the final read clearly indicate that the last sector of the block was not filled (BC=0100H), and the address in DE also correctly shows how much of the buffer was filled.

I'm hoping that HDOS does not gratuitously fill the entire remainder of the buffer with NULs in this case - that would be horribly inefficient for programs using large buffers (like "all of memory").

Unless, HDOS does something abnormal like return EOF when there actually was data returned? I.e. it preemptively returns EOF, unlike pretty much every other OS that returns EOF only when no more data can be read.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBBozbcsZSdFqNb9onmaYdvZ2zpcM7HWtAnf%3DzmURzbgSQ%40mail.gmail.com.

[Douglas Miller]

I've updated the emulator to treat a partial read as an error, returning EOF. This fixed AS.ABS and did not break anything in ASM.ABS, C.ABS, M80.ABS, or L80.ABS.

I see that most other programs, including C.ABS, do 1-sector reads and thus never see a problem.

Thanks, Scott, for raising the issue.

[Glenn Roberts]

Great. Looking forward to trying your emulator Doug!

Sent from my iPad

On May 19, 2023, at 6:58 PM, Douglas Miller <durga...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/8c456f6c-9f1c-8b09-36b0-350863f3b30f%40gmail.com.

[smb...@gmail.com]

Thanks Doug for the quick resolution.

BTW, The emulator is really fantastic -- a real time saver.

Scott