Atari++ 1.81 available for download

[+Spaced Cowboy]

I *really* ought to have thought of that Thank you, that was indeed it for the 'file not found' problem. If I can get the actual binary to run, I'll be very happy  

 

prompt% ./atari++  -InstallEDevice on  -InstallHDevice on -H1Dir `pwd` -InstallHasDisk on

Thor Dos 2.++ V 1.9 Enhanced Density
Copyright (c) 1990-2020 by THOR

D1:DIR
  ATARISIOHPP 045
  ANTIC   O   305
  PATCHPROHPP 018
  CARTSDX D   004
  MAIN    O   059

  ... There are a lot of files here ...

  XFRONT  CPP 028
  STRING  O   003
999 FREE SECTORS

D1:OUT.COM

D1:

 

Having looked at the memory map, I tried re-basing ORG= to $6000, which ought to have been out of the way, but it still just returns. 

 

Hmm. Now I think about it, it's possible that it's me using channel 0 (which is usually open to the screen) without actually opening it for these quick-and-dirty test routines before I actually get a version of 'stdio' up and running. Perhaps on this OS it's not open by default. I need to get crt0.xt working anyway, so I can put it in there and try again.

 

Ok, the plot thickens. I was fiddling around trying to see if there was a "stop the emulator now" from within the emulator, and I saw the 'run' command. Not really expecting anything to happen, I tried:

D1:RUN 6000
0
2
4
6
8
10
12
14
16
18

D1:

 

... and it worked! 

[dmsc]

Hi!

7 hours ago, Spaced Cowboy said:

So this is an old thread, but I thought I'd necro-bump it

 

I was looking around for a way to create a test-suite for my new language, and I came across atari++, I'm running on a Mac, so Altirra isn't really an option unless I want to mess about with Wine, and Atari800MacX doesn't seem to want to compile on modern Macs. What really caught my eye about atari++ was the E: and H: drivers combined with a "headless" mode. That seemed tailor-made for what I wanted to do...

 

Run a script, which

• Reads a source file, runs the compiler and produces an executable (.XEX)
• Runs the emulator, in headless mode, and pipes in the path to the XEX (using the H: driver to map a convenient directory where the XEX is)
• Use the E: driver to get the results back from the executable
• Compare the output with an expected output for that test
• Lather, rinse, repeat.

 

For this, I use my own simulator: https://github.com/dmsc/mini65-sim  , this is a *text mode* emulator, it allows you to run simple programs in the command line and get the output to a file so you can check if the result is ok.

 

For Fastbasic, I created a program the run the test-suite and automatically checks the output, for example:

- This program exercises array access: https://github.com/dmsc/fastbasic/blob/master/testsuite/tests/arrays.bas

- This is the script with the expected output: https://github.com/dmsc/fastbasic/blob/master/testsuite/tests/arrays.chk

 

The advantages of the mini simulator are:

- Much faster than other emulators, as it does not emulate graphics and sound, only the CPU.

- It logs calls to OS functions, making possible to check that the correct calls were made (for example, for graphics, plot, etc.)

- Emulates a DOS accessing the host file-system, so you can open "D:myfile.txt" and read files without need of an ATR image.

- Has an integrated tracing and profiling. The profiler can identify unused areas of code or branches that are never taken.

- You execute a XEX program simply by name: "atarisim myprog.xex"

 

The disadvantages: as it does not emulate the full Atari, you can't use it to check for ANTIC, GTIA or POKEY usage, you can only check if the register were written. For a language development, this is not a problem.

 

Have Fun!

 

[+Spaced Cowboy]

Thanks, I’ll definitely take a look at mini65-sim 

[thorfdbg]

Sorry for jumping on this so late - is there still anything to be done for the emulator?

 

[luckybuck]

An integration of the FujiNet-Adapter in your marvelous emulator would be Christmas of the decade. 🙂

[+Spaced Cowboy]

2 hours ago, thorfdbg said:

Sorry for jumping on this so late - is there still anything to be done for the emulator?

 

So I actually integrated dmsc's simulator into the Makefile - it seems to be pretty much designed for doing what I want to do, and it's all working now so I'll probably stick with it.

 

In terms of what I found, these may or may not be helpful

 

• There's the mentioned missing ';'at the end of line 31 in new.hpp - this stops clang from compiling the source, even though it's pretending to be 'gcc'
• There are a lot of warnings from clang, but everyone has their own policy on compiler warnings - mine is not to judge, because everyone uses their own compiler and every compiler is different. To the extent that getting code to run across multiple systems was a harder test to pass than 'lint' IMHO 
• I didn't investigate closely because I got atarisim to work easily and quickly, but writing to CIO with X=0 didn't seem to produce any output; subsequently calling the code using RUN xxxx did, though I only ever did that second (after something else had already written to the screen). I'm wondering if the '0' device isn't open to the screen by default as it is on the XL/XE (and on Atari800MacX). This could be a deliberate choice, and certainly the "correct" way is to call CIO 'open' before writing to it, but thought it was worth mentioning if you're trying to be most-compatible.

 

[thorfdbg]

Merry Christmas, Atarians!

 

It's release time for the 1.85 release of Atari++, as usual on http://www.xl-project.com/

 

I found a couple of improper exception handling cases in the code where you could not reach the menu or emulator any more if the code didn't like your configuration. I also (hopefully) fixed compilation issues with clang and g++ by updating the configuration script, which is now more careful about selecting proper compiler flags. Thus, it should now compile fine with clang.

 

Please let me know if there is anything else broken.

 

Greetings,

Thomas

[_The Doctor__]

except not for windows atm