8bit-Dude

Hi Mozz! Are you still looking into this? I have been mulling something along the same lines myself for a while, I would be interested to bounce ideas together.

I could still fake it with a video, by running it on an Atari ST! ?

It's been a while since I last posted something... Check out these screenies from the "Aztec" and "Desert" maps:

Of course, but then the game would only work on the XE!

No I cannot. This games needs about 10K for the charset/tileset/charmap, about 5K for network code, and so on... I was already closed to maxxed out with the current implementation. I might perhaps try to generate those immediate loads / indirect addressing code blocks when setting the sprite.

Alright, after playing around with this for a while, I now understand how the engine can be so fast. Instead of just storing the sprite bytes and transferring them by indirect addressing, it relies on lists of immediate loads (like lda #0) followed by absolute,X stores (like sta $C600+0,x). This saves quite a bunch of cycles when setting the sprites, but..... it takes up a huge load of memory. Especially because the instructions are repeated twice (for PMG 0/1 and 2/3). Each sprite takes up about 6~8 times more memory space. I won't be able to use the engine for 8bit-Strike, as I have 112 x 8 x 16 multicolor sprites (that would take about 28K of memory instead of 3.5K currently).

Thanks for the tip! I remember using G2F a few years ago, I forgot that it supported a "MIC" format. ?

The engine's demo sure looks impressive! But I had never heard of the "MIC" image file format before. Is there a PNG2SHP.exe somewhere out there?? (I cannot find any PNG2MIC.exe convertor)

Thanks very much Mr. Fish! I will study and see how I could integrate the engine into 8bit-Unity (some rewriting is probably needed, looks like some macros in there are not supported by ca65).

The example which I posted (http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM) is close to what I would like to achieve. Are there code snippets out there showing how this wizardy was achieved?

This is more or less what I already implemented: re-use of Players in the vertical direction (by updating the XPOS and COLOR on DLI lines).

Hey Guz, Taking inspiration from https://playermissile.com/dli_tutorial/, I implemented vertical sprite multiplexing in 8bit-Unity last year. However the performance is less than ideal in my new game "8bit-Strike". I still get excessive flicker when more than 2 multicolor sprites share the same DLIs. I have seen some pretty impressive stuff on this forum (Like this: http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM)．So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle.... Thanks in advance!

Your code caused a compilation error on beq @IRQexit1 : Error: Range error (130 not in [-128..127]) I fixed it up as follows, which saves 16 bytes from the CC65 version and seems to work correctly: IRQ: lda INTSET ; Poll all pending interrupts and #SERIAL_INTERRUPT bne @doIRQ clc rts @doIRQ: bit TxDone bmi @tx_irq ; Transmit in progress ldx SERDAT lda SERCTL and #RxParityErr|RxOverrun|RxFrameErr|RxBreak beq @rx_irq tsb SerialStat ; Save error condition bit #RxBreak beq @noBreak stz TxPtrIn ; Break received - drop buffers stz TxPtrOut stz RxPtrIn stz RxPtrOut @noBreak: lda contrl ora #RxIntEnable|ResetErr sta SERCTL lda #$10 sta INTRST bra @IRQexit @rx_irq: lda contrl ora #RxIntEnable|ResetErr sta SERCTL txa ldx RxPtrIn sta RxBuffer,x txa inx @cont0: cpx RxPtrOut beq @1 stx RxPtrIn bra @IRQexit @1: sta RxPtrIn lda #$80 tsb SerialStat @tx_irq: ldx TxPtrOut ; Has all bytes been sent? cpx TxPtrIn beq @allSent lda TxBuffer,x ; Send next byte sta SERDAT inc TxPtrOut @exit1: lda #TxIntEnable|ResetErr bra @IRQexit @allSent: lda SERCTL ; All bytes sent bit #TxEmpty beq @exit1 bvs @exit1 stz TxDone lda #RxIntEnable|ResetErr @IRQexit0: ora contrl sta SERCTL @IRQexit: lda #SERIAL_INTERRUPT sta INTRST clc rts

Thanks for that StarGunner! I will check it the code still works with those modifications. If so, it would be worth letting Karri know about it, as he coded the original serial code in CC65!

In order to make it easier for people to start developping games/code using the 8bit-Hub, I have added a folder on GitHub that contains a small demo code written in CC65. See GitHub Code: https://github.com/8bit-Dude/8bit-Hub/tree/master/CC65 See Emulation of 8bit-Hub (Firmware 0.6) in Handy 0.98: http://8bit-slicks.com/?wpdmpro=handy For more info on the 8bit-Hub: http://8bit-unity.com/?page_id=551 Note: This code can be easily ported to assembly. You simply need to use the files hub.s (generated by CC65) and comlynx.s. Then use the same API calls as shown in main.c. ?

8bit-Strike is an online multiplayer game for 8bit consoles, which I have been developping with TIX (sprites/maps) and Minu (maps). I have posted a detailed Atari Lynx Gameplay preview on YouTube, which I am sharing here. For more info: http://8bit-strike.com: for up-to-date news and beta tester registration. http://8bit-unity.com/?page_id=551: for more info on the 8bit-Hub.

Nice contribution Bocianu!!

Here is some technical information on how the engine works ------------------------------------------------------------------- The game only requires to create a couple of bitmaps and text file for each screen. For example: Base bitmap: Animation bitmap: Script file: scene01.txt A python script compiles the text and produces a navigation file (together with a summary image) Navigation summary: So it is very easy to get started!

Indeed! I will make a full disclaimer in the release notes of all the tools/bits of codes that I have integrated, and all the people who are supporting this project! As a technical note here, it is worth noting that Exomizer is used to compress everything (binaries/bitmaps) except for the Atari XEX files. The way CC65 generates binaries for the Atari means that blocks of memory are re-used several times in a staging process. Exomizer is not able to cope with that. Happily, Chris (XXL) came to the rescue with a ZX0 decompressor that integrates with xBios. That really makes a big difference with how much data can be packed onto a single disk!

With the new release of 8bit-Unity 0.5 just around a corner, I am going to post here some news about features. To start with, I made a special effort to improve the "point'n'click" tech demo called 8bit-Goblin. Here is a list of major improvements: - Scripting engine now based on simple "text" files. - Added animation paths (motion coordinates and frames). - Added new targets: Atari 400/800, and NES/Famicom. This updated Tech Demo in 8bit-Unity 0.5 contains everything for you to get writing a point'n'click game!!! For more info, check out: http://8bit-unity.com/?page_id=358

AFAIK, that's what the Arduino does in Digital Output mode. I set the state to HIGH / LOW, which should cause the Trigger to transition betwen 1 / 0. This works fine on 800, 600XL, 130XE, but on the 800XL it takes such as long time that a ldx #255 counter decrements all the way to 0 before the trigger transitions from 1 to 0. It is as if the Atari is fighting against being pulled down on that line...

After some further investigation, it turns out that the issue is with the Joystick Trigger (used as Acknow flag). Switching the Joystick state from low to high seems to take an eternity on the 800XL. I am going to experiment with inverting the default state (low instead of high).

Looking forward to this! I will probably join the action (not sure on what platform yet though!) ?

Thanks for referring this thread ClausB, some very interesting information in there. I am going to try and play with switching frequency, to see if that improves the situation. Maybe not enough time is allocated for the 5V signal to rise back to the point where it can trigger a falling edge again...

I am getting ready to launch the Atari 8bit cable for my 8bit-Hub (see: http://8bit-unity.com/?page_id=551) The system connects to Joy Port 2, using PIA for I/O. Rapid toggling of the first pin (falling edge TTL) is required to trigger interrupts on the Arduino. I have carried out testing with Filippo on various systems, and found the following: - NTSC 800 (1 unit): OK - PAL 800 (1 unit): OK - PAL 600XL (1 unit): OK - PAL 800XL (4 units, some modded with U1MB, Sophia2...): ALL NOT OK! - NTSC 1200 XL (1 unit): OK - PAL 130 XE (2 units): OK As you can see above, the PAL 800 XL is the only model giving an issue with TTL edge detection. I wonder if there is anything different with the chips used in 800XL PAL region???