Jump to content
phaeron

Altirra 3.90 released

Recommended Posts

Posted (edited)

Hello Skr,

 

I am using Window 10. Conjectural 2 Paddles into 1 port. Still failed. That paddles had been tested on real Atari 800XL , works great without any problems. Tested on Arkanoid II. Works fine.

Edited by Caterpiggle

Share this post


Link to post
Share on other sites
11 hours ago, skr said:

I use the VCS Classic Stick, which I connect to my Mac via Blutetooth with Atari800MacX, and the stick works great. But as phaeron said, Paddle is another story. I can read the controller as stick OR as paddle, still have to figure out the details. Evans&Sutherland´s "Digistar 6" recognizes the paddle function, but crashes. When I´m in Salt Lake next time, I´ll talk with the creator of the Joystick.dll about it. Would be to cool to control my digital planetarium with an Atari stick. :)

 

Fun Fact: I can connect the Stick to my Atari 800XL with USB Cartridge (still available from ABBUC, technical Details: https://atariwiki.org/wiki/Wiki.jsp?page=MicroUSB ) and it sees stick and paddle changes. :) Let´s see, what we can do with that. :)

Ha, coincidentally I live in Utah, and also have the USB Cartridge, though have never actually used it yet... bought a bunch of stuff one day and still haven't had the time to use it... take days off and end up just playing Valheim and catching up on sleep...

Share this post


Link to post
Share on other sites
2 hours ago, leech said:

Ha, coincidentally I live in Utah, and also have the USB Cartridge, though have never actually used it yet... bought a bunch of stuff one day and still haven't had the time to use it... take days off and end up just playing Valheim and catching up on sleep...

I´m in Salt Lake City (Actually Sandy, but E&S is uphill at Komas Dr and I spend lots of time there) regularly (have a room at a friend´s house) and take it as base for my road trips. Next planned visit is October, let´s keep in touch. :)

The USB-Cartridge is available for about about 16 years now and no one really did much with it. What a shame, this has to change, I´m just digging into it. So many cool things here that could be connected and used with the Atari. :)

  • Like 1

Share this post


Link to post
Share on other sites

is there any way to emulate this 256k memory expansion? which is not the rambo 256k. 😅

memory.thumb.png.f5ed23c409b698573fd8096a6ac4c076.png

Share this post


Link to post
Share on other sites

When I type an address in the Disassembly window of the debug mode, I got a source listing with that address in the middle. The problem appears when I want to set a breakpoint some pages below: at the click on the required instruction, the listing scrolls back to the typed address, and that was because the focus remained in the combo box.

 

A workaround is to click once in the listing after typing the address to change the focus and then scroll the window looking for where to set a breakpoint.

 

This issue does not happen with Memory windows.

 

I'm not sure if this has been reported... or if it's WAD.

Share this post


Link to post
Share on other sites
15 hours ago, vitoco said:

When I type an address in the Disassembly window of the debug mode, I got a source listing with that address in the middle. The problem appears when I want to set a breakpoint some pages below: at the click on the required instruction, the listing scrolls back to the typed address, and that was because the focus remained in the combo box.

 

A workaround is to click once in the listing after typing the address to change the focus and then scroll the window looking for where to set a breakpoint.

 

This issue does not happen with Memory windows.

 

I'm not sure if this has been reported... or if it's WAD.

No, this isn't intended, there's some B.S. going on with the event notifications from the combo box control. I'll fix it.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey @phaeron,

 

Could we possibly get a command-line option for tape position? Something like /tapepos MM:SS. This would be helpful for tapes that have multiple games and required manual positioning (here's an extreme example).

 

 

Share this post


Link to post
Share on other sites

Can I submit a suggestion for a future version? I think it might be interesting to get feedback on the execution time of direct commands in BASIC. I know that you can use RTCLOK timers in 18,19,20 but it adds extra lines and variables to the programs, you have to be careful with the NTSC/PAL differences and obviously it influences (even in a small way) the execution time of a BASIC program. I was thinking of an additional option in the "Debug" menu or a "View", called "BASIC execution time". In practice, this would be an additional view exactly like "Printer output". This view would show something like:

 

[START: 2021-05-14 15:25:00; END 2021-05-14 15:28:25; DURATION: 00:03:25] CLOAD
[START: 2021-05-14 15:29:30; END 2021-05-14 15:29:55; DURATION: 00:00:25] LIST
[START: 2021-05-14 15:34:00; END 2021-05-14 15:45:25; DURATION: 00:11:25] RUN
[START: 2021-05-14 15:46:00; END 2021-05-14 15:46:01; DURATION: 00:00:01] NEW

For each command entered in direct mode in BASIC, a time counter would keep track of when "RETURN" was pressed for the command to be executed, and another record would be taken as soon as the command finished running. This would make it possible to know the execution time of a command or of a whole program (RUN).

 

If the execution time exceeded 24 hours, the duration would be expressed in hours greater than 24, without additional worries

[START: 2021-05-14 15:34:00; END 2021-05-15 18:22:15; DURATION: 26:48:15] RUN

Subsidiary questions:
- What to do when "System > Warp speed" (F1) is used?
- Could/should this work with other BASICs than Atari BASIC (Turbo BASIC XL, OSS BASIC A+/XL/XE, ...)

Share this post


Link to post
Share on other sites
1 hour ago, ldelsarte said:

Can I submit a suggestion for a future version? I think it might be interesting to get feedback on the execution time of direct commands in BASIC. I know that you can use RTCLOK timers in 18,19,20 but it adds extra lines and variables to the programs, you have to be careful with the NTSC/PAL differences and obviously it influences (even in a small way) the execution time of a BASIC program. I was thinking of an additional option in the "Debug" menu or a "View", called "BASIC execution time". In practice, this would be an additional view exactly like "Printer output". This view would show something like:

 


[START: 2021-05-14 15:25:00; END 2021-05-14 15:28:25; DURATION: 00:03:25] CLOAD
[START: 2021-05-14 15:29:30; END 2021-05-14 15:29:55; DURATION: 00:00:25] LIST
[START: 2021-05-14 15:34:00; END 2021-05-14 15:45:25; DURATION: 00:11:25] RUN
[START: 2021-05-14 15:46:00; END 2021-05-14 15:46:01; DURATION: 00:00:01] NEW

For each command entered in direct mode in BASIC, a time counter would keep track of when "RETURN" was pressed for the command to be executed, and another record would be taken as soon as the command finished running. This would make it possible to know the execution time of a command or of a whole program (RUN).

There's a problem with doing this in that the emulator doesn't know the internals of BASIC, it simply runs BASIC as any other program. As such, it doesn't know about direct mode or statements, and getting that information is dependent on addresses within the specific interpreter -- including the three revisions of Atari BASIC.

 

I think this feature is probably a bit too esoteric to implement, but you can approximate this in the debugger. It's not easy and requires some poorly documented features, but I'll leave you with this riddle:

bx -n "pc=ciov and x=0" \".printf @ts @frame-@t0 ; bp -n -q -o @ra \\\"r @t0 @frame; .sprintf \\\"%%d %.*S\\\" dw(icbll) dw(icbal)\""

If you want fine-grained timing within a BASIC program, however, the debugger can do that via the BASIC mode of its Profile View, as it monitors the publicly documented page zero variables of the BASIC interpreter to identify which lines are being executed. This should work with most Atari BASIC compatible interpreters that use the documented STMCUR variable and will profile execution on a line by line basis:

 

image.png.9bcc059d19b6c7750702e5f3f3c3a17d.png

 

You do have to be careful to start and stop it while the BASIC program is running as it doesn't know when deferred mode starts and ends.

 

1 hour ago, ldelsarte said:

- What to do when "System > Warp speed" (F1) is used?

All timing within the emulation is fully virtualized unless you have added an external real-time base such as R-Time 8. Otherwise, using warp mode will not affect the number of clock cycles or frames it takes to execute code within the emulation.

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
4 hours ago, phaeron said:

I think this feature is probably a bit too esoteric to implement

But thanks anyhow for taking the time to reply with a lot of details. I understand your explanation and I totally see your point.

I didn't realize BASIC was itself a running program, like any other program. Silly me! ;-)

 

I'm having a heated (private) discussion by email with a C64 fan about performance. It's always the same story: measuring the execution time of an Atari BASIC "benchmark" program is not enough to draw a final conclusion about the hardware. That is simply because it evaluates both the Atari hardware AND the Atari BASIC implementation. I try to explain that the Atari BASIC was not designed for raw performance but for its pedagogical qualities: to allow a first-time computer owner to start with a "user friendly" BASIC.

This same "benchmark" program, once translated into another language such as Action! (easily readable for someone who knows Pascal for example) shows that the hardware is really, really well designed. So, in summary, I make performance measurements.

 

Unrelated: I wonder why Shepardon did not implement a CRUN, to be comprehensive (to match the generic SAVE/LOAD/RUN commands). And why not add an optional naming capability such as CSAVE "Laurent's program". The string (program name) could have been saved in the very early records on the tape and displayed quickly when a CLOAD is used. LOADING Laurent's program... Please wait. So that you don't wait 15 minutes realizing afterwards that you loaded the wrong program. I know about SAVE "C:LAURENT.BAS" but this is line 32.768, last one, so it appears at the very end if you read the program char by char. Of course, you can also have a line at the beginning, such as 0 REM Laurent's program and use a LIST "C:", but, you see, I envy the C64 "Loading XYZ" message...

Share this post


Link to post
Share on other sites
1 hour ago, ldelsarte said:

measuring the execution time of an Atari BASIC "benchmark" program is not enough

Well, you may be surprised, even without going to Action... 😁

 

Do you have by any chance a copy, list or link to the actual Basic sample you are discussing?

 

BTW, your explanation is dead-on. (hint: C64 Basic, as supplied, is a derivative of Microsoft Basic...)

 

 

Share this post


Link to post
Share on other sites
9 hours ago, ldelsarte said:

I'm having a heated (private) discussion by email with a C64 fan about performance. It's always the same story: measuring the execution time of an Atari BASIC "benchmark" program is not enough to draw a final conclusion about the hardware.

 

Assessing a personal computer against a BASIC benchmark is akin to choosing a marriage partner according to a magazine "How compatible are you?" quiz.

 

It's an abject means of assessment and is unlikely to lead to happiness...

Share this post


Link to post
Share on other sites

Would it be possible to add more options for saving frames (i.e. screenshots) -  such as assigning a joystick button or keyboard key to auto-saving the frame(s) to a designated folder with a series of numbered files?
I'm finding it challenging getting good screenshots with Alt + F10 and specifying a filename to save to, or Alt + Shift + M to copy a single frame to the Clipboard.

Share this post


Link to post
Share on other sites

Hey there, I have a question for a simple feature request.

There is that really nice "audio monitor" that displays the oscilloscope visualisation of audio channels, as well as some audio channel informations, and I was wondering if it could be possible to display some more details on that overlay?
Something such as the AUDC, AUDF values, on their respective channels, as well as AUDCTL, SKCTL and maybe even RANDOM?


It's most likely already possible to see all of this easily in the debugger, but that sort of visualisation would be incredibly useful for the music experiments I'm doing lately with the POKEY chip :) 

If this cannot be done, or it is a pointless feature request, I understand.

 

Thank you :) 

  • Like 1

Share this post


Link to post
Share on other sites
On 5/14/2021 at 8:09 PM, Faicuai said:

Do you have by any chance a copy, list or link to the actual Basic sample you are discussing?

Apparently a very simple BASIC program, just loops and additions, that some people use for benchmarking:

100 FOR I=1 TO 10
110 S=0
120 FOR J=1 TO 1000
130 S=S+J
140 NEXT J
150 PRINT ".";
160 NEXT I
170 PRINT S

In Action!, it could look like this:

CARD S,I,J

PROC MAIN()
  FOR I=1 TO 10
  DO
    S=0
	FOR J=1 TO 1000
	DO
	  S=S+J
	OD
	PRINTF(".")
  OD
RETURN

 

  • Like 1

Share this post


Link to post
Share on other sites
53 minutes ago, ldelsarte said:

Apparently a very simple BASIC program

😂 👍

 

Will get back to you on this one, via P.M. so we don't pollute the thread.

 

In the mean time, this sample can be run in x10 different ways on the emulator (and real Atari), including Basic interpreters, OS FP-packs, and DMA control (manual, via OS or via XEP80 / Bit3 / 1090 80-columns session)... 

 

  • Thanks 1

Share this post


Link to post
Share on other sites

Ok, so here's a small utility I have been working on (and testing) for a little while.

 

It works on Emulator and real HW, of course, and it allows to "park" the XEP80 Ultra-driver (in memory), and open an OS-based E: session, and launching anything there that cannot run any other way, and then with the exact same utility, return back to XEP80 E: session... just like a virtual graphics "mode", without ever reloading the driver or the OS/SDX session itself.

 

(note: source and object code included below)

 

Scratchpad-DOS-90K-AA.ATR

 

 This will work better with SDX version of Ultra driver (also supplied), and a dual-screen setup on real HW, OR simply manually switching screens on Altirra emulator.

 

The idea is simple:

  • keep the XEP80 driver in MEMLO area (do not remove it, nor change its warm-start hook-up on SDX), 
  • back-up XEP HATABS E: and S: vectors in a "safe" area (for now 6 bytes on $0130 offset in Page-1),
  • reprogramming HATABS with OS default E: and S: vectors (pointing to E400-area table),
  • and finally (cold-calls) to CLOSING and OPENING E:/S: handlers, per HATABS current vectors.
  • It automatically toggles session-states (by going on reverse, above), so it can be called with the exact same name and no parameters.

 

Now, I am not sure if everything is tying-up correctly, because when parking XEP80 E: session, and opening OS E: session, typing "Basic" generates the odd effect of showing text-output on the XEP, while the text associated to keyboard-inputs is still going to OS E: buffer, but can't be seen because DMA is off. A blind "DOS", "enter", "XEP80CTL" sequence fully returns Screen and Keyboard control to XEP session.

 

Is a full CIO restart (on-the-fly) the only way to solve this issue? I just wonder what I'm missing here...

  • Like 2

Share this post


Link to post
Share on other sites

In another post, I wrote the following while testing keys and buttons in 5200 mode:

Quote

BTW, there is a strange behavior with the 2nd button of the sticks. Even though I could read them and assign to shadows, when I perform a Cold Reset (pressing Shift-F5 in Altirra), it seems that bit 3 of SKSTAT remains high even when bits 0-1 of CONSOL change, so all the upper triggers appears as pressed... until one of them is really pressed. It seems to be an issue in Altirra due to the fact that the Shift key was pressed at the moment of the Cold Start. It does not happen when I use the option from the System menu.

I think this is a bug in Altirra, because the same "lock" behavior also happens when using the Cold Reset option from the System menu while pressing the shift key in the keyboard (before going to the menu).

 

Share this post


Link to post
Share on other sites
Posted (edited)

I would like to ask another feature.

 

Add support for maxflash 1 mbyte (8 mbit) cartridge with 39sf040 flash eproms. The difference between the 29f040 ones is that the sectors size to erase are 4kbytes each instead of 64 kbytes. I had some compatibility issues because of that.

 

The data sheet can found at: https://ww1.microchip.com/downloads/en/DeviceDoc/20005022C.pdf

 

Thanks in advance!

Edited by Wilheim

Share this post


Link to post
Share on other sites
4 minutes ago, Wilheim said:

Add support for maxflash 1 mbyte (8 mbit) cartridge with 39sf040 flash eproms.

I think I've asked for something like that in the past, but for sst29sf010 as that has a rather convenient 128 byte sector erase and so can be used as a floppy effectively.

 

The first issue for Altirra is that the carts are mapped to a single type of Flash chip and @phaeron would need to alter the AtariMax flash cart model to support two as the real cart comes stock with 2 x am29f040.

 

The second issue is that there is no additional agreed spec for the CAR header for this as it would need to be adapted to hold the flash chip's ID pair of bytes. 

For example this could go to the last two bytes of the sixteen (so at 0xE and 0xF) and as a fallback, if those are zero, then the default for the cart model would be applied.

Then for the 8mbit MaxFlash then offsets 0xC and 0xD can be the ID for the second chip.

 

So I back the proposal but wanted to highlighted it has outside of Altirra consequences, i.e. other emulators may want to adopt the support too if people make images for it.

Share this post


Link to post
Share on other sites
55 minutes ago, Wilheim said:

Add support for maxflash 1 mbyte (8 mbit) cartridge with 39sf040 flash eproms. The difference between the 29f040 ones is that the sectors size to erase are 4kbytes each instead of 64 kbytes. I had some compatibility issues because of that.

It already does:

 

image.png.14d42638a5215480f7540592fca31614.png

 

The label is wrong, but it is set up for 4K sectors in the flash emulator.

 

41 minutes ago, Wrathchild said:

The first issue for Altirra is that the carts are mapped to a single type of Flash chip and @phaeron would need to alter the AtariMax flash cart model to support two as the real cart comes stock with 2 x am29f040.

I fixed this a while ago, the AtariMax 8Mbit carts now emulate as two separate 4Mbit chips. Haven't heard of carts with heterogeneous chips and I'm not even sure if the flasher will support it.

 

41 minutes ago, Wrathchild said:

The second issue is that there is no additional agreed spec for the CAR header for this as it would need to be adapted to hold the flash chip's ID pair of bytes. 

For example this could go to the last two bytes of the sixteen (so at 0xE and 0xF) and as a fallback, if those are zero, then the default for the cart model would be applied.

Then for the 8mbit MaxFlash then offsets 0xC and 0xD can be the ID for the second chip.

 

So I back the proposal but wanted to highlighted it has outside of Altirra consequences, i.e. other emulators may want to adopt the support too if people make images for it.

I don't think flashing support for MaxFlash is widespread -- a patched Atari800 is I think the other one that supports it...?

 

In any case, a bigger issue is that depending on a particular flash chip is tenuous at best. Atarimax doesn't guarantee that any particular chip will be used and they have switched a couple of times without warning. This is a general problem with devices that have flash in them, they tend to be built with whatever flash chip is available in the right size as the base device doesn't require a particular sector size.

 

  • Like 1

Share this post


Link to post
Share on other sites

That might have also come about from people using their AtariMax carts to flash eeproms for other devices 😀

 

My use case would be assisting in developing a cart based Seven Cities.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, phaeron said:

a patched Atari800 is I think the other one that supports it...?

I first did the routines for A800WinPLus and then Thomas Richter converted them to c++ for incorporating into the Atari++ emulator but flash-writing doesn't appear to have been ported into the Atari800 codebase.

Share this post


Link to post
Share on other sites

Having a problem that could very well be my own stupid programming trick.  (Altirra x64 3.90)  (Test configuration is NTSC Atari 800 OS-B, 48K).

 

I have a line of ANTIC mode 2 text.   Rather than deleting the text from the screen, I just set the everything black ($00)  (COLBK, COLPF2, COLPF1).  

When I put Players 0 and 1 over the place where this  text occurs in Altirra it looks like the text appears over the Players.

I'm pretty sure that before this area of the screen  I have set PRIOR to $01 which should be normal GTIA mode, and the priority control that puts all Players over the playfield.

 

So, I'm having a mental issue trying to figure out why the text is visible over the Players.  

 

Earlier/higher up on the screen the code was using a DLI to game the GTIA 16 grey scale mode with 5th Player to make some color demo joy, and then this PRIOR setting is turned off.   Things on the screen below this point depend on normal GTIA color interpretation and it all looks fine, so I'm pretty sure the GTIA color interpretation mode does get set back to "normal".

 

I've hacked up the DLIs to make sure  PRIOR reset is occurring, redundantly.  

Below is a grab from the Altirra screen where the black text appears on the Players.

The Blue background color is set immediately after the last occurrence of resetting PRIOR.


    lda #[GTIA_MODE_DEFAULT|$01]
    sta PRIOR

 

where:

GTIA_MODE_DEFAULT =  %00000000 ; Normal CTIA color interpretation

and

PRIOR =  $D01B ; Control Priority, Fifth Player and GTIA modes

 

1nv_PMvMode2_screen.thumb.png.a8b7f433c851746c3723ceb57e02b9da.png

 

and here is the GTIA layers visualization to make the text v Players more obvious.

1nv_PMvMode2_gtialayer.thumb.png.e0139cd377e5e87c4d3b3bd1f9c30157.png

 

Am I misunderstanding something about ANTIC Mode 2 and Players here?

 

(and fyi, tested this on atari800 on linux which does not show the text above the Players, but it's known to not show things according to real hardware.)

 

For reference, the current executable is at   https://github.com/kenjennings/Atari-1nvader/blob/master/ata_1nvader.xex

It's just a graphics demo at the moment, not a working game.

 

Thanks.

Share this post


Link to post
Share on other sites
51 minutes ago, kenjennings said:

Having a problem that could very well be my own stupid programming trick.  (Altirra x64 3.90)  (Test configuration is NTSC Atari 800 OS-B, 48K).

 

I have a line of ANTIC mode 2 text.   Rather than deleting the text from the screen, I just set the everything black ($00)  (COLBK, COLPF2, COLPF1).  

When I put Players 0 and 1 over the place where this  text occurs in Altirra it looks like the text appears over the Players.

I'm pretty sure that before this area of the screen  I have set PRIOR to $01 which should be normal GTIA mode, and the priority control that puts all Players over the playfield.

 

So, I'm having a mental issue trying to figure out why the text is visible over the Players. 

Double-checked on an 800XL that yes, you should see the text here.

 

The reason this happens is that hires graphics are special in GTIA: they bypass the priority and palette lookup circuits and go directly to the output logic at the end, where they switch the luminance between the normal output and PF1. The priority logic only works at color clock speed (160 resolution) and only sees PF2 for the hires playfield regardless of the individual pixels. The result is that nothing ever blocks the hires layer, it tunnels through anything and everything and stamps PF1 luminance wherever it is active.

 

As far as I know, Atari800 has also supported this effect forever -- at least as far back as Atari800WinPLus. If you aren't seeing it then either something weird is making the program run differently or you are using an old version of Atari800.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...