fox

I have added HCM to http://recoil.sourceforge.net/

How do I play a note via MIDIMATE? I'm trying the following code but hear nothing in Altirra: org $6000 main sei ldy #7 lda #0 sta:rpl ^20,y- mva #$28 ^28 mva #$15 ^24 mva #$23 ^2f mva #0 ^2e mva #$10 ^2e mvx #$c0 ^2d ldx #$01 ; instrument jsr send ldx #$90 jsr send ldx #$3c ; middle C jsr send ldx #$7f jsr send mva $10 ^2e cli rts send lda #$10 and:rne ^2e sta ^2e mva #$10 ^2e stx ^2d rts run main end

"Almost no restrictions" for the graphicans using it. The difficulties we discuss are for the programmer.

Last week I posted the source code of the Numen demo on GitHub: https://github.com/pfusik/numen

How about we disable playfield DMA in DMACTL during horizontal blank?

Ah yes. Even with one scanline high characters using VSCROL and switching the font every scanline, it's not going to work because same data goes to character names and font. We see four bits of the font, that limits us to just 16 different characters. And there's an AND on the address bus.

If Phaeron is right about AND or OR done on character data, we aren't going to get hardware 80-character mode. Otherwise, it looks possible! (with 4x8 font)

See ANTIC schematics and Altirra Hardware Reference Manual.

ANTIC's internal memory is written in badline, but is it read as well? If so, we have two more problems: - ANTIC will try to write and read the internal memory at the same time? - there are only 48 bytes, what when it overflows?

Yes, any number of lines is possible. Narrow mode would give more time for the 6502. This mode is very intensive on DMA. Also, the memory refresh would be reduced to 1/9 - what will be the effect? Yes, but PMG DMA will get tricky.

Didn't know about that. Any details? Since we fetch the very same byte to name and playfield, this restricts playfield bit 7. Playfield merging could actually help here. This is going to be even harder than I thought. If we cannot workaround the problem of bit 7, it could turn out not really useful.

I think you didn't understand my idea. I want ANTIC to fetch 80 characters per line.

Relocating SAP files is the same problem as relocating 6502 executables. I don't believe it can be implemented for all cases. But for many SAP files it's possible to extract the original module and relocate it. This can be done with asapconv.

I have an idea for a new graphics mode: 160x240x5 colors. Normally, in ANTIC 4 / GRAPHICS 12 the selection of COLPF2 vs COLPF3 is in 4x8 cells. My proposal is to have 2x1 cells. How to do that: First step is having 1 line high cells. This can be done by writing to VSCROL to trick ANTIC to fetch new characters every scanline. This is the easy part. Second step is to double the DMA rate. In the badline of ANTIC 4 the DMA already uses all the cycles in the visible area, alternating between character and font fetch. Using HSCROL, we want to trick the DMA machinery to fetch both characters and font every cycle. Fetching a character every cycle will double the resolution of the 5th color. This will be very tricky, as ANTIC will put both the screen address and font address on the address bus. Using CHACTL to mirror the characters vertically will be probably needed to not have the low-order address lines cleared.

Indus GT emulation with LEDs is awesome! Thank you! Are drive buttons mapped? Also, with http://atarionline.pl/utils/9.%20ROM-y/BIOS-y%20-%20stacje%20dysków/Indus%20GT%201.4.romI'm getting error 139 on track 27 of Numen_A.atr. Edit: http://atarionline.pl/demoscena/B/Bitter%20Reality.atrdoesn't boot.

What are these bars (in corners and right side) in Full Overscan GTIA mode 10?

Interesting topic, I need to visit this forum more often. HiassofT's calculations are interesting, but for me 1.11 sec program loading time feels just as good as 0.16 sec, not "seven times slower" and most of Atari users don't have that fast storage. The data we compress now is usually bigger than 8k, so a compressed program takes several seconds less to load from a standard drive, which does make a difference for me. What's more important, disk and memory capacities are limited. For example, Numen wouldn't fit on 2*130k floppy and in 320k RAM without compression. Did you notice there's background decompression running in the demo and it's the old "inefficient" code? Obviously, I optimized "inflate" for size and not speed. Nevertheless, it's always been much faster than the old-school "crunchers" which decompressed with dots and bars on screen for several seconds. peteym5, I'm curious about more accurate time comparison. I've reviewed your code. I like the way you handled 256-byte sequences. Some comments: bcc inflateCodes_loop inflateCodes_loop This bcc is pointless. sta inflateCodes_sourcePointer php sta inflateCodes_sourcePointer One sta is enough. clc inflateCodes_setOffsetHighByte You can remove this clc now. ;TYA lda inflateCodes_length Why not use tya instead of the lda?

1977, page 63: "Atari should start making its smart telephone".

First Time Setup is great! However there's a problem selecting PAL, here's my bug report: Environment: 1. Altirra 2.81 or 2.90-test18. 2. Windows 10 64-bit. Steps: 1. Using regedit, delete HKCU\SOFTWARE\virtualdub.org 2. Run Altirra.exe. 3. Next. 4. Scan folder for firmware images, select a directory with all the ROMs. 5. Next. 6. Next. 7. Next. 8. PAL, Next. 9. Next, Finish. 10. File/Boot image, Strip Poker.atr 11. Close "Altirra Error". System/Firmware/Internal BASIC. System/Cold Reset. Expected: 1. No HKCU\SOFTWARE\virtualdub.org registry key. 2. First Time Setup opens. 3. ROM selection. 4. All ROMs "OK". 5. ROM setup complete. 6. System selection. 7. Video standard selection. 8. Experience selection. 9. Self Test. 10. System stopped. There could be an option to enable BASIC. 11. Game title screen. Music plays slowly as in PAL. Actual: 10. System stopped. No option to enable BASIC. 11. Game title screen. Music plays fast as in NTSC. Selecting Video/PAL (although it's already selected) resolves the problem.

For my Bresenham routine see mocap/mocap.asx in http://numen.scene.pl/download/numen_src.zip

Hi Phaeron, Can we please have a screen keyboard for Windows 8.1 tablets? You could probably use a keyboard drawn some 15 years ago by PG if he doesn't mind.

Please try "New Art" from http://atarionline.pl/v01/index.php?ct=utils&sub=2.+Grafika Setup an ST mouse in port 2. Then in the editor RMB opens a menu in Atari800 Win PLus but not Altirra 2.70-test4.

I don't know how you got these numbers, but back in the 1990s there was a benchmark showing that a 1.77MHz 6502 clearly beats a 4.77MHz 8088 in speed.

Xuel, I'm impressed! I wouldn't explain it any better. I admit that headers generation is somewhat messy: - opt h- and opt h+ can switch header generation - org $a000 is a no-op if *==$a000 (saves an unnecessary header) - ... except when it's org a:$a000 or org f:$a000 - opt f+ inserts padding instead of a new header

There are two problems with your modified code: 1. MODUL no longer points to the module's address. It points to where some previous code ended. 2. Location of starttune is unclear. You expect it to be located after the module, yet you insert bytes including the header starting from the module address. There are several possible solutions, e.g. a. Move starttune next to the rest of your code and keep just the module at the end: opt h- MODUL equ $a400 ins "music.rmt" b. If you really like the code to follow the module and the module is stripped from instrument names, insert just the contents without the headers: org $a400 MODUL ins "music.rmt",6 ; skip 6 leading bytes, ie. the header starttune ldx #<MODUL ldy #>MODUL lda #0 jmp RASTERMUSICTRACKER As a bonus, from xasm 3.1.0 on you can even take the loading address directly from the module file, e.g. org {ins "music.rmt",2}+{ins "music.rmt",3}*256 instead of org $a400 This way the address of your module won't get out of sync with your source code.