The 40 year old AVR mega Basic interpreter is now on my Blog

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

I made an update to my blog, the first since 2012.  This is the port of the 1977 Basic interpreter I have been working on all winter.  40 years in the waiting.   It is not complete there is no file or program store load I/O yet.  Some of he cursor I/O in the terminal emulator still needs updating.  But the math package is installed   As far as I have tested the baseline functionality is there. it can run simple programs and gives the same answers as the emulated version.

 

here is a link to the project blog http://www.delectra.com/toys/?p=145

Grab a pot of tea before reading, The blog posting is long, covering 40 years of semi-biographical history relating to he Nostalgia for this footnote to the history of computing.  Plus there have been no blog updates on the blog for 6 years.  Well the B in Blog is supposed to stand for Boring.  I did my best to make it entertaining, you have been warned...

 

For the non historian direct link to the photo of the project  (the big orange square is a peice of paper covering the LED that would blind the camera sensor) :

Arduino AVR hardware running 1977 Basic

 

For the truly adventurous, who like complex way over bloated auto generated hand edited assembly code the project source Git link is: https://github.com/sheepdoll/PTExtendedBasicArduino

There is not enough free memory to run any of the game demo.  This will  have to wait for the Mega 1248P-Xplained Hardware version, which at 11 Mhz will be too slow for the TFD.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool beans!! A very interesting project.... There is something satisfying that doesn't include Cortana!

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used to lust after the SOL-20!  (one of many, I guess.  But I let myself be lured away by mainframes and arpanet.)

 

Neat project!   Your blog is in need of sub-titles...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhh! Sol!

Sorry, I couldn't help it!!!!! 

The SOL 20 didn't really appear on the radar out here, at least for me. Mind you, I was fairly young at the time. I do remember the trs80 and a friend had an Imsai 8080 with Persci drives (these were voice coil as opposed to stepper - in an 8" floppy drive). My school had a Cromemco C3 (memory is hazy) running Cromix. A little out() instruction from mbasic was all it took to crash the computer. i guess it wasn't expected that a spotty little kid understand the hardware and the bank switch register!

Anyways, nice work. how does the size of the AVR binary compare with the 8080's?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

 

Anyways, nice work. how does the size of the AVR binary compare with the 8080's?

 

Seems to be about 1/3 larger.  There is no size optimization, this is a straight up mnemonic swap. There are a few macro where there is not a direct corelation.  A lot of the instructions such as the conditional returns turn into 2 instructions  these are going to be either 2 or 3 instruction words.   The XGNG instruction  was origionally a call return, then I realized the movw works on any register si it became a 3 instruction macro.

 

It this were re-coded to to take advantage of the native AVR architecture, it probably would come out the same, or possibly a bit smaller.  A lot of the 8080 code has to move data in and out of the accumulator.  As any AVR register can accumulate this byte moving could be done away with.   There are places where this data moves in pairs.  The extra registers could also be used to  of load some of the more frequently used memory location pointers.  There are a lot of lds/sts which could be handled with ld/st offsets into the extra registers.

 

An experiment I may try is since the AVR registers are memory mapped would be to move these frequent lds/sts accesses to unused registers rather than SRAM.  Free up a few bytes that way and make debugging easy as one would then see the pointer in the register.    The BCD code uses a lot of offsets into the digits, these could advantage from the LD/ST offset indirect.  Some of the registers could be used instead of the temp locations.   These are all exercises for the reader ...

 

The computer retailer I went to work for in 1982 sold  Cromemcos.  When the Apple brand really took off after the Apple /// fiasco (they were 100% DOA)  I was hired as part of the salvage operation.  Apple ///s were great computers.  Not one of the customers I had ever regretted buying them.  

 

The retailer dropped the Commodore and Cromemco brands and became an exclusive Apple dealer.   Eventually around 1985 they started carrying IBM and Compaq brands.  I think we sold the Comemco, that Panama used for it's passport/immigration system.  Not sure I ever want to travel to Panama.

 

The trash 80 used the same Video system as the Sol.  It was actually a bit of a clone and the hardware was open.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’ll probably get to see a real Sol at the computer history museum next week. The family is making a pilgrimage to the land of Apple and American Girl Dolls. I’ll get to see for myself if the Bob’s Burgers depiction of the American Girl Doll shop is true.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh.  I had not remembered that it was actually an S100-based system (5 slots.)