Image Map Image Map
Results 1 to 10 of 10

Thread: Running Altair 8K basic 4.0 in my emulator - problems

  1. #1

    Default Running Altair 8K basic 4.0 in my emulator - problems

    Not sure if anyone has any tips on what to try. I've tried making a loader for the TAP format files on the altairclone site, and I found binary files for them as well and just load them in. Both do the same thing:

    Code:
    MEMORY SIZE?
    TERMINAL WIDTH?
    WANT SIN-COS-TAN-ATN? N
    
    ?OV ERROR
    
    MEMORY SIZE?
    This happens if I try the 4K basic 4.0 or the 8K basic 4.0. I get an OV error, but it seems like sometimes I've seen an OM error as well.

    Then I tried basic extended 40 and it will get out of the prompt, but its numbers are not right, print 2+2 results in J0 and the bytes free is "502R4" for some reason.

    Code:
    MEMORY SIZE?
    WANT SIN-COS-TAN-ATN? N
    
    502R4 BYTES FREE
    ALTAIR BASIC REV. 4.0
    [EXTENDED VERSION]
    COPYRIGHT 1977 BY MITS INC.
    <trapout 02,01>OK
    
    print 2+2
     J0
    OK
    I am masking the character to be printed on the screen with 0x7F to drop the top bit. My 8080 emulation passes the cpu tests, but maybe there is still something there.

  2. #2

    Default

    Well, it works with the other i8080 emulator code so it must be something in my emulator. I'll trace it.

  3. #3

    Default

    I figured it out.

  4. #4
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,847

    Default

    It might be interesting for others to know what you did wrong and how you fixed it - especially if the 8080 CPU test gave your emulation a 'clean bill of health'.

    This would indicate that the 8080 CPU test has some 'holes' may be?

    Dave

  5. #5

    Default

    I agree - it was very surprising that it made it through the crc test and other cpu tests - that I am still a little surprised about, but I suppose it goes to show that tests are not the end all.

    The problem was I have my flags in separate uint8_t variables - it seemed to run faster in my DOS compilation test and I know on some systems like 8-bit AVR's, that a bitfield will result in a read-modify-write cycle so I had the idea that I thought was good at the time to allow my flags to be either in two states, zero or non zero as opposed to the two more defined states 0 and 1. Well, the non zero state ran into some problems with the add functions because carry could be 1 or 128 or some other bit value. I still find it surprising that the cpu test did not catch it. Through it may be a little more work and an instruction or two more to go back to a pure 0 and 1, this is what I did for now. Still using the separate uint8_t for each flag, but long term I'll try that against the bitfield again to see which is faster.

  6. #6
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    3,847

    Default

    I came across a similar issue with FORTRAN LOGICALs a few years ago.

    FORTRAN has .TRUE. and .FALSE. which generally equate to .FALSE. == 0 and .TRUE. anything else other than zero.

    However, when interfacing between FORTRAN and C, you have to be a bit more careful. Some FORTRAN compilers permit logicals to be either 0 and non-zero OR just the least significant bit is the critical data item. This works fine if everything is compiled using one or the other methods - but I came across an example where some code was compiled one way - and other code compiled another. Providing they didn't share variables - everything appeared to work fine... As soon as the application 'grew' and some logical variables were shared - all sorts of strange behaviour arose!

    It took me a while to work out what was happening - but the customer was quite impressed that I found the problem for him - just not overly happy with the software contractor's that created the problem for him in the first place !

    Dave

  7. #7

    Default

    That is exactly what happened here. Usually in C you have "zero" and "non-zero" and a lot of instruction sets do similar JZ vs JNZ. And in truth it isn't C's fault, it was mine when I decided to "+Carry" thinking it would be a 0 or a 1. Totally my fault, but this falls under bad idea (bad practice, anti-pattern, etc.). I could have coded around it in the add function by making it be +(Carry?1:0) but then you get to why not just store it the right way in the first place.

  8. #8

    Default

    Many moons ago I wanted my brand new Heathkit H89 to do something besides provide 5.25 inch beer coasters for my friends who had never actually seen a computer before, much less have any idea what a floppy disk was. I decided to see if I could get the programs in this book to run on it.

    https://en.wikipedia.org/wiki/BASIC_Computer_Games

    In the process I was repeatedly bit by variations of how different versions of BASIC represented something as simple as a Boolean value. "FALSE" was usually 0, but "TRUE" could be: anything other than 0, O.001, or O.377 depending on the whim of the designer. As long as you stuck to logical operations, the games all mostly sorta worked when ported to Benton Harbor BASIC. But at least one of the games used a Boolean as an operand in an arithmetic expression. That took a while for a noob programmer to figure out.
    "It's all bits on the bus, Cowboy! It's all bits on the bus!" -- Tom Beck, #1ESS Instructor, Southern Bell Opa Locka Training Center

  9. #9

    Default

    DDS - I've always found BASIC variation to be a big pain too.

    It is surprising how something simple like a boolean variable can be so complicated - I was looking at this yesterday about C and booleans - look at how complicated it gets:

    https://stackoverflow.com/questions/...an-values-in-c

  10. #10

    Default

    Some benchmarks so far on my i8080 code for those who are fascinated by such things:

    i8080 running 8080exm test on P3 700 MHz
    DOS (cycle counting off) = 72.909 MHz (9.60 : 1)
    XP WIN32 (cycle counting on) = 100.174 MHz (6.99 : 1)

    i8080 running 8080exm test on 486 DX2 66 MHz
    DOS (cycle counting off) = 6.337 MHz (10.52 : 1)
    NT4 WIN32 (cycle counting on) = 4.900 MHz (13.61 : 1) (overhead of NT on limited CPU probably the cause! or perhaps the 486 is just not all that optimized for 32bit as the P3?)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •