Altirra 2.70 released

[serj]

thanks, Avery.

but...

 

some cartridges began to work at the emulator incorrectly.

 

ROBOsoft Cartridge Turbo 2000 (v1).bin

in beta 18 continuous reset.

in beta 17 - worked.

 

Info-Cell Turbo 2000 (v1).rom

 

in beta 18 continuous reset.

in beta 17 - worked.

 

visicopy3.car or visicopy3 [Phoenix 8KB cart].bin

 

in beta 18 - hangs.

in beta 17 worked.

 

carts.zip

[phaeron]

Try now:

http://www.virtualdub.org/beta/Altirra-2.80-test19.zip

http://www.virtualdub.org/beta/Altirra-2.80-test19-src.zip

[serj]

excellent !

all works.

Thank you Avery !

 

it is possible to ask to add one trifle to the emulator?

if it is possible, add please memory type "4kb ram" for atari 400/800.
I read that such was.
simply for the sake of historical interest.

[MaPa]

I want to ask about watch byte debbuger feature.. does it work or it is broken now? I'm coding something after a long pause and it don't work anymore, at least I think I use it correctly.. I just type in console "wb index" for example and it should show on screen value of index variable, shouldn't it? But it does nothing now.

Edited February 22, 2016 by MaPa

[Heaven/TQA]

oh... does watchbyte work in that way? cool...

 

btw... can you track down memory leaks? means... triggering & watching memory blocks which should not hit but if code gones mad get triggered?

 

think of having in memory an exompized (packed) code... now if some other code running prior hits that area (it's enough that 1 byte of the packed data gets changed fex.) the depacking will fail...

[MaPa]

Just discovered that something is wrong in altirra.ini. If i remove it, it works.

 

EDIT: just found that it's caused by Direct3D 11 (experimental) setting

Edited February 22, 2016 by MaPa

[flashjazzcat]

btw... can you track down memory leaks? means... triggering & watching memory blocks which should not hit but if code gones mad get triggered?

Phaeron will probably be able to suggest something more sophisticated, but in its simplest form:

 

bx "write >= $4000 and write <= $7FFF"

 

This will trigger a breakpoint on any write in the defined region.

[Heaven/TQA]

now thats cool!

[phaeron]

if it is possible, add please memory type "4kb ram" for atari 400/800.

I read that such was.

simply for the sake of historical interest.

 

How do you get a 4K Atari? As far as I know, the smallest RAM cartridge designed for the 800 was 8K, and all other machines shipped with a minimum of 16K.

 

Phaeron will probably be able to suggest something more sophisticated, but in its simplest form:

 

bx "write >= $4000 and write <= $7FFF"

 

This will trigger a breakpoint on any write in the defined region.

 

Shorter version: ba w 4000 L4000

[+David_P]

I think (and ClausB can probably confirm) that a few early engineering models had 4K; before they hit production, RAM prices came down enough for 8K to be the minimum.

 

EDIT: See: http://atariage.com/forums/topic/122471-atari-800-engineering-serial-26

[serj]

 

How do you get a 4K Atari? As far as I know, the smallest RAM cartridge designed for the 800 was 8K, and all other machines shipped with a minimum of 16K.

 

https://en.wikipedia.org/wiki/Atari_8-bit_family

 

The early machines: 400 and 800

After announcing the intent to enter the home computer market in December 1978,^[10] the machines were first presented at the Winter CES in January 1979 as the 400 and 800.^[11] The computers shipped in November 1979, much closer to the original design date. The names originally referred to the amount of memory, 4 KB RAM in the 400 and 8 KB in the 800. However by the time they were released the prices on RAM had started to fall, so the machines were instead both released with 8 KB. As memory prices continued to fall Atari eventually supplied the 800 fully expanded to 48 KB, using up all the slots. Overheating problems with the memory modules eventually led Atari to remove the module's casings, leaving them as "bare" boards. Later, the expansion cover was held down with screws instead of the easier to open plastic latches.

 

it would be interesting such to see in the emulator.

to add it to the emulator for you won't make complexity.

simply one more pleasant trifle.

Edited February 23, 2016 by serj

[Mclaneinc]

Serj, not having a go, I love almost all your idea's but I'd suggest its best to stick to the final production Atari's otherwise you could go down the path of looking at what was planned to go on the Atari at some stage but was scrapped, should these be added for historical significance, I say no because its a rabbit hole to nowhere.

 

Apart from the fact a 4K Atari never made it to final I can't see the use of it from a software point.

 

I truly love your enthusiasm Serj but making a version of a machine that never made it to the masses just seems a bit pointless as would producing a version with stuff that never made the final cut.

 

Anyway, its all up to Avery, just saying my thoughts..

[+DrVenkman]

Serj, not having a go, I love almost all your idea's but I'd suggest its best to stick to the final production Atari's otherwise you could go down the path of looking at what was planned to go on the Atari at some stage but was scrapped, should these be added for historical significance, I say no because its a rabbit hole to nowhere.

 

Well by that logic, why emulate anything but production models? Why have support for 65816 processors, 3rd party memory upgrades - modern or historical - or present day IDE carts, etc?

 

It's Avery's choice of course but that said, your logic doesn't hold.

 

 

Sent from my iPhone using Tapatalk

[Mclaneinc]

More because these upgrades exist and a 4K Atari never did beyond pre production. Your take on my logic is flawed because you make it based around what was actually produced by Atari when I said it was about items that were actually made and available which includes 3rd party stuff and lets not forget new upgrades are still being made while a 4K Atari would be a down grade if anything

 

But as we both say, the bottom line is that its Avery's choice which is the be all and end all.

Edited February 23, 2016 by Mclaneinc

[drac030]

When doing some tests on Altirra 2.70-release, I noticed that the emulated IDE+ quite often loses its NV-RAM settings. Especially after "System"->"Cold reset" is selected. It is quite irritating and I do not observe this on real hardware (which I use a lot).

[phaeron]

Well, 65C816 based machines at least exist, have utility, and have software written for them. On the other hand, we don't really have any evidence of 4K machines existing out of prototypes or any reason to emulate them. Sometimes I emulate things in Altirra because they have negative value, i.e. programs break in that configuration. In that case, even if something has no usefulness to an end user, it can be useful to emulate so programs can be debugged. Abnormal DMA is an example of this. Seeing has though no one has a 4K machine short of accidentally having bad RAM, this doesn't really apply either. Not to mention, I haven't heard a lot of use of the 8K mode either, which at least is a configuration that could be created readily by memory cartridges that were released.

 

So, serj -- thanks for the suggestion, but I think I'll decline for now.

 

When doing some tests on Altirra 2.70-release, I noticed that the emulated IDE+ quite often loses its NV-RAM settings. Especially after "System"->"Cold reset" is selected. It is quite irritating and I do not observe this on real hardware (which I use a lot).

 

Post 2.70 I found an issue with some IDEPlus settings not saving because the emulator had been mistakenly unilaterally blocking writes to RTC RAM location 1, under the impression that it was always read-only per the datasheet. This was stomping some settings in the IDEPlus menu and the latest 2.80 test releases no longer do this. When you have time, could you try 2.80-test19 or later and see if the behavior is improved?

[Roydea6]

700 RT=54712
710 POKE RT,3:WD=PEEK(RT)*10+PEEK(RT):
POKE RT,4:M=PEEK(RT)*10+PEEK(RT):POKE
RT,5:Y=PEEK(RT)*10+PEEK(RT)
720 POKE RT,0:S=PEEK(RT)*10+PEEK(RT)
OKE RT,1:MS=PEEK(RT)*10+PEEK(RT):POKE
RT,2:HMS=PEEK(RT)*10+PEEK(RT)
730 ? M;"/";WD;"/";Y+2000

With this listing and Altirra 2.70 test xx I am not getting the proper answer, but with Atari800 WinPlus I get this response 2/23/2016 .

rtime8 option is checked in both emulators.

[phaeron]

This is a bug in Atari800WinPlus -- it always reports 0 for the upper 4 bits when reading the R-Time 8. On real hardware, these bits will either be all 1s or floating bus data depending on the computer. Altirra used to do the same until I fixed it a while back. See this thread for more info (amusingly, you're in it too!):

http://atariage.com/forums/topic/196599-ice-t-xe-273-released/?p=2522543

[drac030]

Post 2.70 I found an issue with some IDEPlus settings not saving because the emulator had been mistakenly unilaterally blocking writes to RTC RAM location 1, under the impression that it was always read-only per the datasheet. This was stomping some settings in the IDEPlus menu and the latest 2.80 test releases no longer do this. When you have time, could you try 2.80-test19 or later and see if the behavior is improved?

 

I found no later one than test-19. It shows the same issue here. I setup the settings (CONFIG.SYS D3:, USpeed SIO on, US on D1 on, Z: driver off, APE time off, defaults to everything else), reboot with them (Ctrl/B), SDX starts, I can do software restart (COLD from the cmd line) with no bad effects, but selecting "System"->"Cold Reset" causes the settings to be lost instantly. It is immediately visible because SDX attempts to start from D1 then, which is not online

[phaeron]

Hmm. I would like to fix this, but I am unfortunately still unable to reproduce this. I upgraded the IDEPlus 2 firmware from 1.3 to 1.4 and matched the settings, but wasn't able to get it to happen. The real-time clock chip state is not reset on a Cold Reset, which it probably should be, but that shouldn't cause a problem unless the IDEPlus clock driver left it in a weird state AND the BIOS also didn't fully reset the read sequence, which I don't see happening. The emulator loads the NVRAM from the Registry when the device is added and saves it on removal, not on reset, so that can't be it.

 

Is anyone else still experiencing this issue?

[drac030]

Do not bother, I have finally managed to reproduce the problem on real hardware. The issue is caused by hitting the Reset key (or powering the computer down) when the BIOS procedure is in the middle of reading the clock. E.g. when TD Line is installed or anything else which is reading the clock state repeatedly. It seems pure luck that it is so obtrusive on the emulator and has not virtually occurred to me on the real hardware (both configs feature the same ultimate cause of the problem). Maybe I rarely have a reason to hit reset.

 

So, there is nothing to do on the Altirra side. Apologies for bothering you.

[phaeron]

Do not bother, I have finally managed to reproduce the problem on real hardware. The issue is caused by hitting the Reset key (or powering the computer down) when the BIOS procedure is in the middle of reading the clock. E.g. when TD Line is installed or anything else which is reading the clock state repeatedly. It seems pure luck that it is so obtrusive on the emulator and has not virtually occurred to me on the real hardware (both configs feature the same ultimate cause of the problem). Maybe I rarely have a reason to hit reset.

 

So, there is nothing to do on the Altirra side. Apologies for bothering you.

 

I actually knew about this problem, but avoided bringing it up because it is listed as a known issue in the IDE Plus 2.0 Configuration Screen Guide. From what I recall, it's a result of the BIOS having to temporarily overwrite the configuration data in RAM to read the clock and then to write it back, an unfortunate requirement of the way the 3021 RTC works. Are you saying that the issue occurs on real hardware, but with much less frequency than in the emulator? If so, there may still be something for me to fix.

[Mclaneinc]

@DrVenkman, my apologies, I reread my post and it didn't mention 3rd party stuff, sorry, it was my intention at the time to say that but somehow between thinking and typing it went missing.

 

You were 100% right in your reply based upon what I had written.....

 

A proper person knows when to apologise for his or her mistakes...This is my time (most likely of many...)

Edited February 26, 2016 by Mclaneinc

[Keatah]

For anyone wanting to simulate a 4k machine, just limit your software to that 4k. Pretend the rest don't exist none, yeh?

[fujidude]

For anyone wanting to simulate a 4k machine, just limit your software to that 4k. Pretend the rest don't exist none, yeh?

 

Yes indeed. You know I get a kind of a smile and chuckle when reading all this talk about dreams of 4K RAM. Never ever did I imagine I would observe anyone wishing for a memory reduction, less alone down to 4K.

Edited February 26, 2016 by fujidude