[Disabling the built-in E: editor]

E: only gets to do such processing if it's asked to.

In a user program situation that involves calling CIO with the appropriate channel opened already.

 

All that's needed here is to close IOCB #0.  In fact you could get away without doing that so long as you can guarantee that CIO won't be called to do E: output.

A quick and dirty way to mark an IOCB as closed is to just put value $FF into ICHID ($340 in this case) - this serves as index into the handler table to tell CIO which device is open on the IOCB, value $FF flags that the IOCB is closed.

[Disabling the built-in E: editor]

Close is the easy bit.

Various things can open it agan - warmstart of course, and if you're in Basic or many other language processors, an error condition or program ending.

Returning to Dos from an application also.

 

Are you replacing E: or just employing code that does the IO processing all by itself?
In theory you could still use K: to get the keystrokes then just deal with them as you like.

[Question RE opening E: at Cartridge INIT as opposed to Cartridge Start]

A real Atari XL would have revealed the problem by the SIO polling noise as it will attempt to download a non-present handler.

It can be missed in emulation because we usually run SIO/turbo patches which will usually suppress the feedback.

[Question RE opening E: at Cartridge INIT as opposed to Cartridge Start]

It should work then.

Maybe check a disassembly/debug in Altirra to ensure the proper values are being used and that nothing is being overwritten.

[Question RE opening E: at Cartridge INIT as opposed to Cartridge Start]

Correct - E: isn't open when cart INIT is called which can come in handy in that you use it instead as a run address with the benefit of no annoying blue flash plus you have a mostly initialized system.

 

What text is at SEDS?

As a minimum it should contain E and the Return ($9B) character sequence.

I do suspect if it doesn't have the Return character that the open won't work properly.

 

[anyone have the .ATR ('s?) for Miner2049er?]

It was originally cartridge release, I don't know if it was officially on any other media type.

But in the day I had a cracked executable file version.

The one on Fandal's site is an Xex also - https://a8.fandal.cz/detail.php?files_id=2361

 

[DLI Programming....locating Display List Interrupts before display list?]

Then you have the immediate VB problems -

Too long running code can cause shadow register copies to be delayed, in extreme cases the DList pointer could be stored after the display has started which can make the screen jump.

Too long running code will disrupt SIO operations.

 

But in general for game/demo purposes immediate mode is often best.

You can prevent deferred mode from being skipped but at the cost of turning off the keyboard IRQ which can be inconvenient.

[Masked and non-masked blit procedure for 320px wide 1-bit screen (HiRes, GR8)]

Unrolled code can be used which can help speedup.

 

Also, self-modifying code.  And a combination of the two.

Heaven posted a thread some years back about Zone Ranger (can't find the thread) - it uses Ram-based code sections which render an entire column at a time.

From memory it uses indexed addressing and the routine is first modified to insert an RTS at the relevant part then you enter it at the appropriate place and the unrolled code runs faster because it's not having to use indirect addressing.

It's another case of sacrificing memory to gain performance.

I seem to recall at least one thread discussing various softsprite rendering techniques but again, no links.

[Masked and non-masked blit procedure for 320px wide 1-bit screen (HiRes, GR8)]

There's various ways depending on what speed you want and how much memory you can sacrifice.

 

The fastest method is to have pre-computed (shifted) data and masks.  Slowest is to just have the basic data and do the shifting every time.  Also there would be the option of whether to save/restore background data or just do an erase before redraw.

 

There's also the XOR method where sprite data is just EOR'd to the background once then do again which performs an erase.  The validity of using this method can vary depending on how much is going on and what background data will be present but plenty of games in the day used it.

 

I believe there's code examples around though don't have links.

[Altirra Hardware Ref Guide]

I'd have to check again as my info is a bit rusty.

But hires on final scanline is possible without distortion, though the fix involves hitting DMACTL at the right time during that scanline then leaving playfield DMA at 00 until after VSync.

Something like that anyway but bottom line was it was a fair bit of effort for not a lot of gain.

[Display list help?]

Actually, it's PRINT #6 which causes the cursor artifacts.

As an alternative you could get away with just straight PRINT statements, and also get rid of the POKE 87 to change what the OS thinks the mode is.

The problem with telling it you're in Gr. 2 is that you'd then limit screen operations to only the first 240 bytes of screen memory.

[ACTS - Atari Computer Test System]

Don't think I've heard of it before.

The doc isn't clear on how the test program is introducted to the UUTs in the 128 computer rack being tested.

I would guess that possibly it is via a SIO boot.  Alternatively it could be on cartridge.

There would be a fair amount of custom cabling in use - the test sequence does IO to the PIA as well as to it's associated interrupt lines as well as joystick bits and POT inputs.

Maybe like the SALT hardware test board but on steroids.

[Display list help?]

The Gr. 0 gets offset like that because you have 3 x Gr. 2 lines which use 60 bytes of screen data.

So you end up with that unwanted offset.

Correction could be by adding another LMS to skip another 20 bytes so the Gr. 0 starts at the right offset, or just add another 20 bytes mode line before the Gr. 0 starts.

 

[Altirra printer output screen -- 40 columns only?]

I'm getting 40 cols regardless whether I use LPRINT, ? # or LIST "P:"

 

Maybe it's version dependent?  That was in 3.90

[Selfmade 256K Expansion for 800XL - Rambo & XE Compatibility Questions]

It's my understanding that banking systems that don't support seperate Antic/CPU banking will have all memory accesses directed as per PORTB setting.

Main memory mirroring - I'm not sure if this is relied on much.  I guess it's a side-effect of the way some expansions work.  The main useful purpose would be to get at the Ram under $D000-$D7FF that's normally not accessible on a stock machine.

[How many different fonts could you have on screen theoretically at the same time?]

VScrol tricks to create shorter characters mean you can have the PF2/PF3 choice in a smaller area.

It can become wasteful though.

A good compromise can be using 4 scanline high chars, then you can use CHACT to flip the characters such that the entirety of the font data is used.

Though if you're doing a bitmap simulation you'd likely be using 120 characters only so 8 would go to waste.

[Virtual Light Machine using Tapes?]

I suppose the conversion circuit could potentially recognise parts of audio as FSK tones but don't think it would correlate to any particular beat or frequency within the music.

In a lot of cases we could see visual representation of such a thing and think otherwise.

The processing power needed to produce much useful - remember that the PS1 wasn't even fast enough to do MP3 playback.

Similar things could have been done on the Falcon but it has the benefit of the DSP.

[How many different fonts could you have on screen theoretically at the same time?]

With the swirl effect where you have image change that can occur practically anywhere, the only way you could do that in bitmap is by bankswitching on a 128K or higher machine.

Additionally to enable the character set change on any line, there's VSCROL tricks in use so that there's only a badline at the top of the window, otherwise you'd not be able to do the change in hires char modes on the first scanline of each character.

[Total number of A8 units sold worldwide = ?]

Would have to hope it was in the 4 million region.  Even the C128 sold around 2.5 and it was a released when 8-bit machines were becoming obsolete.

Wiki only has the C64  at 12.5 to 17 million, but other sources have it at 17-30.

 

Apple II estimates say around 6 million.  So given they had much better software support later on than ours, maybe the Atari sales were a bit lower than 4 million.

 

[Virtual Light Machine using Tapes?]

There were sampling devices that used the joystick ports, not sure if they uses POT input or digital via the stick pins (maybe both?)

 

The problem though is that to get any sort of meaningful analysis of the audio in real time you'd be left with barely any CPU time to do graphics rendering.

[Screwy 6502 ASM question.....]

.help in the Altirra debugger lists available commands.

 

There's other ways to do it but you can use BA R <address> which should stop execution when that address is read, including if it's part of the program itself.

Then you can just F11 to single step.

 

The old Atari AsmEd cart was not bad in this regard - it has the T and S commands in Debug to Trace or Step execution.

[Screwy 6502 ASM question.....]

NOP does nothing except burn cycles.  But can also have effect on offset for nearby branches and change address for subsequent instructions.

But what you have going on there looks normal enough.

CPX #0 type of thing is only needed if there were instructions since X was last modified that could have changed the P flags.

Checking a disassembly can help.  Stuff like landing addresses for JMP/JSR/branches being right, and working variables being in the right place, ie make sure you're not inadvertantly corrupting your own program.

Altirra can come in handy also - single step after halting the program via a read address trap.

[Atari 400 Some letters not right]

Weird one - an early thought was error from sequential memory accesses but it's only the character set accesses that are faulty.

Maybe A3 to the E Rom?

But you'd have to think that if that address line was stuck, there'd be no way the OS would properly work.

[storing string data, both kinds, as program line numbers. Possible?]

Another thing to note re memory usage.

Not stacking stuff into lines or having the max amount of data in one line can be very wasteful.

Each program line has overhead, so the idea of using one string per line then associating the line number with it would almost certainly cost more in terms of Ram used.

[storing string data, both kinds, as program line numbers. Possible?]

I don't get what you're attempting with line numbers.

Line numbers are stored as 16 bit binary with limit 0-32767 in the program.

They are sorted in memory low to high regardless of what order they get entered.

 

So for storing anything they're not all that useful.  I guess you could use reserve line numbers above a certain range, e.g. 2000 onwards and use certain line numbers which could then be chained through to extract some data.

2000-32767 would give a range if 30767 to store integer constants.  But then you'd need code to chain through it to extract the data.

Lines of Basic code have a built in overhead though, so it's not a mega efficient way to store things.

You'd probably do better by just embedding data direct into strings.  But a problem there is you can't easily generate CHR$(155) which is the Return key - you have to generate it with extra statements.