PucMon

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
at67
Posts: 190
Joined: 14 May 2018, 08:29

PucMon

Post by at67 » 06 Jun 2020, 08:52

Here's a link to the latest video and I have attached the .GT1 file for anyone who wants to give it a try.
https://www.youtube.com/watch?v=jXiNF7V9IMI

ROMv3
PucMon.gt1
(14.11 KiB) Downloaded 43 times
ROMv5a
PucMon_ROMv5a.gt1
(14.69 KiB) Downloaded 52 times

I used these two references to code the AI:
https://gameinternals.com/understanding ... t-behavior
https://www.gamasutra.com/view/feature/ ... ossier.php
Last edited by at67 on 19 Jun 2020, 11:40, edited 3 times in total.

delpozzo
Posts: 21
Joined: 03 Jun 2020, 18:47

Re: PucMon

Post by delpozzo » 09 Jun 2020, 15:01

I'm quite new to Gigatron, but I was able to load .gt1 files via BabelFish and an Arduino Uno last night for the first time. Just wanted to say great work on PucMon, it worked flawlessly on my Gigatron and ran very smooth. I'm very impressed with all the work you've done, especially on gtBASIC and the gtemuAT67 emulator. I was also blown away by the Parallax demo, I think it's really cool that the Gigatron is capable of such effects. I hope to make a game sometime soon in the near future :-)

at67
Posts: 190
Joined: 14 May 2018, 08:29

Re: PucMon

Post by at67 » 09 Jun 2020, 16:16

delpozzo wrote:
09 Jun 2020, 15:01
I'm quite new to Gigatron, but I was able to load .gt1 files via BabelFish and an Arduino Uno last night for the first time. Just wanted to say great work on PucMon, it worked flawlessly on my Gigatron and ran very smooth. I'm very impressed with all the work you've done, especially on gtBASIC and the gtemuAT67 emulator. I was also blown away by the Parallax demo, I think it's really cool that the Gigatron is capable of such effects. I hope to make a game sometime soon in the near future :-)
Cheers for the feedback and congratulations on getting code downloaded into your Gigatron :)

With respect to writing games/apps for the Gigatron and learning it's capabilities there are many ways to produce a .gt1 file and test code in emulators and on hardware.

-16bit vCPU assembly code using a couple of different assemblers, (Tetronis, Bricks, Frogstroll were all written in vCPU). This is the instruction set that most applications/games are written in that run from RAM. It is an interpreter than runs during non video cycles within the 8bit Native code.
- GCL, Marcel's homage to retro languages, (Gigatris and many sample programs were written in GCL), that is an extremely efficient compiled language that has an almost 1 to 1 relationship with 16bit vCPU assembly whilst providing some high level language constructs, (the development environment is Python based).
- Multiple interpreted BASIC's, MS-BASIC, CBM-BASIC, Tiny BASIC.

Tiny BASIC allows really simple and quick access to and experimentation with the Gigatron, you can follow Marcel's and Walter's Tiny BASIC guide here, (https://gigatron.io/?page_id=1234), and with simple Peek's and Poke's come to a quick and decent understanding of the Gigatron's architecture, features and limitations. Once you get a grasp of the basic architecture and have an idea of what is possible with it, it then becomes much easier to choose the language that you want to develop your game/app in.

For the ultimate challenge you can also code in 8bit Native assembly code, (this is what the firmware and ROM's are written in). Native code is based on a Harvard architecture and runs exclusively from ROM, (video/audio generation, input handling, vCPU interpreter, etc are all Native code running from ROM).

Whatever you decide to do, please share your results and keep us updated; the one thing I truly know about Marcel, is that he wanted the Gigatron and the community surrounding it to not only survive, but to thrive.

delpozzo
Posts: 21
Joined: 03 Jun 2020, 18:47

Re: PucMon

Post by delpozzo » 10 Jun 2020, 14:14

at67 wrote:
09 Jun 2020, 16:16
delpozzo wrote:
09 Jun 2020, 15:01
I'm quite new to Gigatron, but I was able to load .gt1 files via BabelFish and an Arduino Uno last night for the first time. Just wanted to say great work on PucMon, it worked flawlessly on my Gigatron and ran very smooth. I'm very impressed with all the work you've done, especially on gtBASIC and the gtemuAT67 emulator. I was also blown away by the Parallax demo, I think it's really cool that the Gigatron is capable of such effects. I hope to make a game sometime soon in the near future :-)
Cheers for the feedback and congratulations on getting code downloaded into your Gigatron :)

With respect to writing games/apps for the Gigatron and learning it's capabilities there are many ways to produce a .gt1 file and test code in emulators and on hardware.

-16bit vCPU assembly code using a couple of different assemblers, (Tetronis, Bricks, Frogstroll were all written in vCPU). This is the instruction set that most applications/games are written in that run from RAM. It is an interpreter than runs during non video cycles within the 8bit Native code.
- GCL, Marcel's homage to retro languages, (Gigatris and many sample programs were written in GCL), that is an extremely efficient compiled language that has an almost 1 to 1 relationship with 16bit vCPU assembly whilst providing some high level language constructs, (the development environment is Python based).
- Multiple interpreted BASIC's, MS-BASIC, CBM-BASIC, Tiny BASIC.

Tiny BASIC allows really simple and quick access to and experimentation with the Gigatron, you can follow Marcel's and Walter's Tiny BASIC guide here, (https://gigatron.io/?page_id=1234), and with simple Peek's and Poke's come to a quick and decent understanding of the Gigatron's architecture, features and limitations. Once you get a grasp of the basic architecture and have an idea of what is possible with it, it then becomes much easier to choose the language that you want to develop your game/app in.

For the ultimate challenge you can also code in 8bit Native assembly code, (this is what the firmware and ROM's are written in). Native code is based on a Harvard architecture and runs exclusively from ROM, (video/audio generation, input handling, vCPU interpreter, etc are all Native code running from ROM).

Whatever you decide to do, please share your results and keep us updated; the one thing I truly know about Marcel, is that he wanted the Gigatron and the community surrounding it to not only survive, but to thrive.
Thank you for your reply at67, this is fantastic information and I truly appreciate it!

I have been tinkering around with Tiny BASIC for a week or so and have had a lot of fun peeking and poking around. The Tiny BASIC guide on the gigatron website is excellent, I pretty much ran through every example and I would definitely recommend it to anyone who is getting started. However, I noticed that the performance is a bit on the slow side so I can see how it isn't the #1 choice for game development.

I'm not feeling brave enough (yet!) to code in 8Bit native assembly, but I'm very interested in both GCL and gtBASIC. I will certainly share my results and keep the community updated regarding my progress ^_^

at67
Posts: 190
Joined: 14 May 2018, 08:29

Re: PucMon

Post by at67 » 16 Jun 2020, 17:36

I've done as much as I can with the 32K RAM model, here are some links to a video and the .GT1 files for ROMv3 and ROMv5a/DEVROM.

ROMv3 plays the same game as ROMv5a but is missing all the sound effects and only has the intro tune for audio.

https://www.youtube.com/watch?v=jXiNF7V9IMI

ROMv3:
PucMon.gt1
(14.11 KiB) Downloaded 33 times
ROMv5a/DEVROM:
PucMon_ROMv5a.gt1
(14.66 KiB) Downloaded 49 times

*Edit* New versions attached: fixed sound issue for ROMv5a, previous versions work fine on all other ROM's, including DEVROM; (see this thread viewtopic.php?f=4&t=232&start=10#p1464)

delpozzo
Posts: 21
Joined: 03 Jun 2020, 18:47

Re: PucMon

Post by delpozzo » 17 Jun 2020, 13:45

at67 wrote:
16 Jun 2020, 17:36
I've done as much as I can with the 32K RAM model, here are some links to a video and the .GT1 files for ROMv3 and ROMv5a/DEVROM.

ROMv3 plays the same game as ROMv5a but is missing all the sound effects and only has the intro tune for audio.

https://www.youtube.com/watch?v=jXiNF7V9IMI

ROMv3:
PucMon.gt1

ROMv5a/DEVROM:
PucMon_ROMv5a.gt1


*Edit* New versions attached: fixed sound issue for ROMv5a, previous versions work fine on all other ROM's, including DEVROM; (see this thread viewtopic.php?f=4&t=232&start=10#p1464)
Awesome job at67! I was able to play the v3 variant on my Gigatron and the v5a variant in the emulator-- both worked great. It looks and plays like the real deal! I was never great at Pacman, but managed to get to level 6 on my Gigatron :lol:

Out of curiosity, what improvements were made in the ROMv5a/DEVROM that allowed you to implement the sound FX vs ROMv4? My Gigatron is currently running v4 and I was thinking about getting an EPROM programmer and another EPROM chip to upgrade to the DEVROM.

at67
Posts: 190
Joined: 14 May 2018, 08:29

Re: PucMon

Post by at67 » 17 Jun 2020, 15:17

delpozzo wrote:
17 Jun 2020, 13:45
I was never great at Pacman, but managed to get to level 6 on my Gigatron :lol:
I've played it hundreds of times over the last few weeks and haven't got past level 7, so you're doing much better than I am; it's still nowhere near as brutal as the real PacMan though.
delpozzo wrote:
17 Jun 2020, 13:45
Out of curiosity, what improvements were made in the ROMv5a/DEVROM that allowed you to implement the sound FX vs ROMv4? My Gigatron is currently running v4 and I was thinking about getting an EPROM programmer and another EPROM chip to upgrade to the DEVROM.
There is a bunch of great stuff in ROMv5a and DEVROM that Marcel was working on, but the main thing that gtBASIC and PucMon utilise is the CALLI instruction.

CALLI allows vCPU code to CALL/JUMP anywhere in memory with one instruction totaling 3 bytes and without destroying the contents of the accumulator, (vAC).

In ROMv4 and lower whenever gtBASIC wants to jump between 256 byte pages or smaller fragmented segments such as the 96 byte offscreen video memory area, it must perform a thunk, (page jump), like this:

Code: Select all

        STW    vAC_save
        LDWI   Label
        CALL   vAC
            .
            .
Label:
        LDW    vAC
You'll notice the page jump requires a prologue and epilogue, which makes this thunk a rather costly 9 bytes for every call/jump that is required. The way the compiler works is that it does not require the programmer to care about segmentation or fragmentation from a coding standpoint. i.e. as a programmer you can merrily produce code until you run out of RAM, (and you will).

To facilitate this the compiler must be able to insert these page jumps/thunks anywhere in the code as you leave one page/segment and enter another. It achieves this by keeping a list of free RAM pages and segments that are allocated based on code size, (individual instructions and groups/macros of instructions). As the virtual program counter approaches the end of a page/segment, the code thunk is inserted and code is relocated and shuffled around. As you can imagine if a thunk is inserted early in the code, it can cause a cascade effect that causes even more thunks to be inserted and even more relocations further on down the line. GCL and raw vASM on the other hand expect you to micro-manage everything, including this aspect of your code, they give you the flexibility to design the memory layout of your project as you see fit to achieve the greatest possible efficiency; but it becomes extremely time consuming and tedious as your project gets bigger, (I spent about 50% of my time on memory layout and organisation when coding Tetronis).

Once the remaining RAM becomes so fragmented, (segments <25 bytes in size), the thunk becomes a significant percentage of the code, (normally <10%, but in this situation approaching 50%), this leads to drastic code inefficiency, wasted RAM and slower effective code execution. When your project gets to this stage, it's time to do some major re-shuffling, moving data structures around and re-organising code order can have a significant effect on how much relocation is performed and how many thunks are generated. (The compiler has many pragma's and options to control this aspect of code generation and thus allows you to squeeze out every possible non fragmented byte of RAM for code and data).

CALLI solves these issues like this:

Code: Select all

        CALLI Label
            .
            .
Label:
So instead of a 9 byte thunk that must save and restore vAC, (because it can be inserted literally anywhere in code), we have a 3 byte instruction that is able to both CALL a subroutine and jump to anywhere in the full 64K address space. So thunks are reduced in size to 1/3 but also CALL's of subroutines and the runtime, (which there can be hundreds of), are reduced from 5 bytes to 3 bytes as well. gtBASIC actually has two completely separate versions of the runtime, one for the 9 byte thunk and 5 byte CALL and one for the optimised 3 byte CALLI thunk and CALL. By specifying a ROM version pragma at the beginning of your code, you can automatically link with whichever version of the runtime you require.

TLDR:
So to finally answer your question :) CALLI saved me around 850 bytes of much less fragmented RAM, which was enough to allow for the programmatic generation of the sound effects. PucMon ROMv3 has around 400 bytes of badly fragmented RAM free and PucMon ROMv5a has around 650 bytes of much less fragmented RAM free.

P.S. The insertion of the 9 byte thunk into every page/segment boundary could be optimised by statically analysing the code and determining if vAC actually needed to be saved and restored. Then the compiler could switch between a 5byte and 9byte thunk producing more efficient code and RAM usage. Unfortunately this is not a trivial problem to solve as it is much more complex than just analysing LDW/STW pairs, thus the effort required to achieve potentially questionable gains deterred me from going down that path. A much simpler and better solution with much higher efficiency, is to just get all Gigatron owners to update their ROM's to either 5a or DEVROM and make CALLI thunking the defacto standard or do what I do now and just provide both versions.

delpozzo
Posts: 21
Joined: 03 Jun 2020, 18:47

Re: PucMon

Post by delpozzo » 18 Jun 2020, 18:27

I've played it hundreds of times over the last few weeks and haven't got past level 7, so you're doing much better than I am; it's still nowhere near as brutal as the real PacMan though.
FWIW, I was never able to get past level 4 in the original Pacman :oops:
...CALLI saved me around 850 bytes of much less fragmented RAM, which was enough to allow for the programmatic generation of the sound effects. PucMon ROMv3 has around 400 bytes of badly fragmented RAM free and PucMon ROMv5a has around 650 bytes of much less fragmented RAM free...
Thank you again for such a great in-depth answer, this is fascinating to me and really helps my understanding of what's going on. It's neat to get the backstory and learn of all the hard work and improvements that have been made.
A much simpler and better solution with much higher efficiency, is to just get all Gigatron owners to update their ROM's to either 5a or DEVROM and make CALLI thunking the defacto standard or do what I do now and just provide both versions.
So you've convinced me to update my ROM :D Would the following tools be sufficient to get the job done?

Programmer: https://www.amazon.com/ARCELI-TL866II-P ... 07CQQBGVK/
EPROM: https://www.amazon.com/M27C1024-10F1-M2 ... 07W7XXWJC/
Software: https://gitlab.com/DavidGriffith/minipro/

I wasn't sure if the suffix on the EPROM, for example the 10F1, 12F1, 15F1 in M27C1024-XXXX makes a difference or not for compatibility?

klf
Posts: 9
Joined: 10 Jan 2019, 22:48

Re: PucMon

Post by klf » 18 Jun 2020, 18:50

This is the access time rating. You will need 150ns or faster. So all three versions should work.

at67
Posts: 190
Joined: 14 May 2018, 08:29

Re: PucMon

Post by at67 » 19 Jun 2020, 02:01

- Programmer looks good, I have the same one. Be careful when programming the device, make sure you choose the correct device ID in the programmer software as different manufacturers/models of devices not only have different programming strategies but also different programming cycle times and voltages, (incorrect settings can degrade the EPROM's life or even potentially destroy it).

- I have no idea about the software, (someone else may have experience with it as it's designed for Linux). I use the bundled Windows software that came with my programmer on a Windows machine.

- WTR to the EPROM's, if they are not specified as unused/brand new, then it's probably a good idea to assume they are sold in used condition. In which case they may need to be erased before you can program them. If you do need to erase them then generally you need a reliable UV light based EPROM eraser, don't try urban myths/legends of natural sunlight or Fluro's etc.

Here's a decent article describing some of the pitfalls and methods when erasing/programming EPROM's.

https://xtronics.com/wiki/How_EPROMS_Work.html

Post Reply