[coleco] add pragmas for OS7 features?

[tschak909]

Would it be possible to add pragmas or be able to specify the addresses for the OS7's spirte nametable, sprite order table, buffer, and controller map tables?

Code: Select all

    defb    0x55, 0xaa        ;Title screen + 12 second delay, swap to not skip it
    defw    0                ;Sprite name table for BIOS
    defw    0                ;Sprite order table for BIOS
    defw    0                ;Buffer for BIOS
    defw    0                ;Controller map for bios

and for e.g. to flip the splash screen on/off/set the splash screen string?

p.s. this is part of work being done here:
https://github.com/tschak909/os7lib

which along with eoslib and smartkeyslib, I still want to give to the z88dk project.

-Thom

[dom]

I think it makes sense to create the space for them as well if they are enabled - that way they can play nicely with other z88dk variables.

Code: Select all

[8000, 8002) - AA 55 or AA 55
[8002, 8004) - pointer to sprites table (NULL or 0x7XXX)
[8004, 8006) - pointer to sprites order table (NULL or 0x7XXX)
[8006, 8008) - pointer to RAM space (NULL or 0x7XXX)
[8008, 800A) - pointer to joysticks (NULL or 0x7XXX)
[800A, 800C) - start address for game

Joystick table is 12 bytes long - how long are the two sprite tables and the bios buffer?

[tschak909]

I am currently looking that up. Taking me a bit longer than expected!

-Thom

[tschak909]

Am currently thumbing through THIS manual, section 10:
https://drive.google.com/file/d/14mnwjq ... sp=sharing

and it literally looks like the answer is "variable" to try and figure this out I scribbled down the values of every single cart that Coleco released, and put it here: https://github.com/tschak909/os7lib/blo ... xamples.md

I'm trying to understand the method of the madness by reading through the manual.

-Thom

[tschak909]

The OS7 absolute listings have this to say:

os7-top.png

-Thom

[tschak909]

So far, I've seen that ACTIVATE uses the work buffer:

activate.png

-Thom

[tschak909]

PUTOBJ seems to be the big user of the work area:

put_object.png

[tschak909]

Slowly figuring out how it works...
https://youtu.be/c3qpWArf_vk

Code: Select all

struct _targGraphics
{
  unsigned char obj_type;
  unsigned char first_gen_name;
  unsigned char numgen;
  void *generators;
  Frame *frame[8];
};

struct _targFrame
{
  unsigned char x_extent;
  unsigned char y_extent;
  unsigned char generator_0;
  unsigned char generator_1;
};

// Extents must be at least 1, 0 causes a pre-decrement wrap to 255
const struct _targFrame targFrame0 = {2,1,0x60,0x61};
const struct _targFrame targFrame1 = {2,1,0x62,0x63};
const struct _targFrame targFrame2 = {2,1,0x64,0x65};
const struct _targFrame targFrame3 = {2,1,0x66,0x67};
const struct _targFrame targFrame4 = {2,1,0x68,0x69};
const struct _targFrame targFrame5 = {2,1,0x6A,0x6B};
const struct _targFrame targFrame6 = {2,1,0x6C,0x6D};
const struct _targFrame targFrame7 = {2,1,0x6E,0x6F};

const struct _targGraphics targGraphics={0,0x60,16,_targ_right_patterns,{targFrame0,targFrame1,targFrame2,targFrame3,targFrame4,targFrame5,targFrame6,targFrame7}};

Status targStatus;
unsigned char targOldScreen[2];
const SMO targSMO={targGraphics,targStatus,targOldScreen};

int i=0;

void targ(void)
{
  SignalNum wait;
  
  activate(&targSMO,false);
  
  for (i=0;i<256;i++)
    {
      targStatus.x++;
      targStatus.frame++;
      targStatus.frame &= 0x07;
      
      activate(&targSMO,true);
      put_obj(&targSMO);
    }
}

[tschak909]

man, somebody at COLECO worked _REALLY_ hard on this graphics package. They genuinely tried to cover all the bases they could think of.

[tschak909]

Am currently documenting my adventures through OS7 at AtariAge:
The latest post to the Exploring #ColecoVision OS7 thread is up. I am currently figuring out how MOBILE OBJECTS work. These use the pattern table like SEMI-MOBILE objects, but can be placed in single pixel increments. #gamedev #retrogaming #retrocomputing https://forums.atariage.com/topic/35475 ... nt=5317028

@dom the hope here is to get answers to the questions you're asking.
-Thom

[dom]

I feel like opened a can of worms.

Really interesting archaeology though!

[tschak909]

@dom Oh no, this was definitely my fault.

I'm trying to figure out enough so I can give reasonable answers to help.

The current binding on github is REALLY close, and right now, i'm just writing tests and figuring out how the pieces work (and in the process figure out how much RAM is used for the different features).

I will re-state, that Coleco was SERIOUSLY trying their hardest to make a re-usable set of routines for graphics and sound output, and I become more sure of this, the more I poke at it to do things. I completely understand now exactly WHY they were able to knock out so many high quality games in roughly a year and a half.

Another random interesting tidbit. Coleco actually intended for at least SOME of the games to be written in Pascal. Yes, the HP 64000 systems they were using had a Pascal compiler option, so they wrote marshalling routines in the ROM for each call, and two games were written in Pascal, the original version of Donkey Kong (The pack-in cart), and Smurfs: Rescue in Gargamel's Castle, the first two games written. Donkey Kong was later rewritten in assembler, to cut it down from 24K to 16K (cost reduction) but is almost functionally identical. I was able to settle this long standing debate by writing a program that scanned for the Pascal vectors, and flag them, showing which ones were used.

-Thom

[stefano]

You're awakening my interest
Really I could never be of any help with the Coleco target, but those efforts with a Pascal cross development are something which happened also elsewhere (the earlier 16 bit Apple systems, in example).
Please keep on digging into the code

[tschak909]

Indeed. I'm one of the few people outside of Apple who actually wrote a Lisa Office application (a simple to-do list program) using the Programmer's Workshop, the Clascal compiler, and the Lisa Office Toolkit libraries (which were hard to source together back THEN, but just as hard now, oddly enough.)

-Thom

[tschak909]

Still trying to grind through os7lib. Mobile objects seem to be tripping me up, and am not sure how much of this is conflicting with os7lib, versus z88dk, etc.

but, I'll try to disclose as much info as I can here:

Current test rom for mobile objects, supposed to draw pac-man across screen:
https://github.com/tschak909/os7lib/blo ... c/mobile.c

and rom:

mobile.zip

Diff for rom.asm

Code: Select all

diff --git a/lib/target/coleco/classic/rom.asm b/lib/target/coleco/classic/rom.asm
index c5168eec53..21a754da0d 100644
--- a/lib/target/coleco/classic/rom.asm
+++ b/lib/target/coleco/classic/rom.asm
@@ -9,13 +9,13 @@
     EXTERN    asm_interrupt_handler
 
 
-    defc    CRT_ORG_BSS = 0x7000        
+    defc    CRT_ORG_BSS = 0x70BA        
     defc    CRT_ORG_CODE = 0x8000
 
     defc    TAR__fputc_cons_generic = 1
     defc    TAR__no_ansifont = 1
     defc    TAR__clib_exit_stack_size = 0
-    defc    TAR__register_sp = 0x7400
+    defc    TAR__register_sp = 0x73B8
     defc        CRT_KEY_DEL = 127
     INCLUDE "crt/classic/crt_rules.inc"
 
@@ -24,7 +24,7 @@
     defb    0x55, 0xaa        ;Title screen + 12 second delay, swap to not skip it
     defw    0                ;Sprite name table for BIOS
     defw    0                ;Sprite order table for BIOS
-    defw    0                ;Buffer for BIOS
+    defw    0x702C                ;Buffer for BIOS
     defw    0                ;Controller map for bios
     defw    program                ;Where to start execution from
 IF ((__crt_enable_rst & $0202) = $0002)

I keep trying though.

Peek 2023-09-17 21-01.gif

-Thom

Peek 2023-09-17 21-01.gif

[tschak909]

Why, is this program:

Code: Select all

#include <os7.h>

void main(void)
{
}

generating 427 bytes of BSS right off the bat?

Code: Select all

total 44
drwxr-xr-x 1 thomc thomc     6 Sep 17 22:38 build
-rwxr-xr-x 1 thomc thomc   785 Sep 17 22:37 Makefile
drwxr-xr-x 1 thomc thomc    22 Sep 17 22:38 src
-rw-r--r-- 1 thomc thomc   427 Sep 17 22:38 wtf_BSS.bin
-rw-r--r-- 1 thomc thomc    21 Sep 17 22:38 wtf_DATA.bin
-rw-r--r-- 1 thomc thomc 32768 Sep 17 22:38 wtf.rom

The ColecoVision has 1K of RAM, guys... sigh...

-Thom

[dom]

Why, is this program:

Code: Select all

#include <os7.h>

void main(void)
{
}

generating 427 bytes of BSS right off the bat?

Because following the "make it work by default" mantra it's pulling in the VDP library which includes a 256 byte scroll buffer for mode 2.

I've added a couple of memory tweaks by default, so the base is now: 355 bytes. Let's say you're not going to use stdio (so no printf -pragma-define:CLIB_FOPEN_MAX=0): 325. If you're not going to use the screen printer (-pragma-define:fputc_cons=0): 65 bytes. We might as well disable setting of the screen mode on startup as well (-pragma-define:CLIB_DEFAULT_SCREEN_MODE=-1): 42 bytes

Of that 42, we've got: 18 bytes for NMI handlers, 18 bytes for im1 handlers. A couple of bytes for handling the VDP status register and some misc lifecycle variables.

It's possible to disable/override the provided NMI and im1 handlers so that you're just left with pretty much nothing.

[tschak909]

Yup, ironically, the IM handlers aren't needed because OS7 handles that, just need to set addresses in the header...

[dom]

Crappy numbers, but you get the drift:

Code: Select all

-pragma-define:CRT_ENABLE_NMI=2 -pragma-export:_z80_nmi=0x66

Code: Select all

-pragma-define:CRT_ENABLE_RST=0x80 -pragma-export:_z80_rst_38h=0x38

From: https://github.com/z88dk/z88dk/wiki/Cla ... -behaviour

[tschak909]

Been a while, but I've been hard at work tearing OS7 (and Donkey Kong apart), am still in the middle of it, but:

Ghidra. Is. Awesome.

It has opened up the code for OS7 and helped me connect all the dots, so I can e.g. understand what all uses the four buffer pointers at the top of the cartridge. e.g. the work buffer is mostly used by PUT_OBJ, and the generator transformation routines (reflect, enlarge, rotate, etc.)

I am putting my results in the os7lib repo in the sre folder, and am doing it in both ASCII and Ghidra ZIP format (the latter can be reconstituted in Ghidra as a project).
https://github.com/tschak909/os7lib/tree/main/sre

ghidra_a1.png

And it can show me a complete flow of a given function, this is the macro view of PUT_OBJ, it's huge:

put_obj.png

Zoomed into the top level object:

put_obj_2.png

It's taking a BIT longer than I had anticipated, but that's okay.

-Thom

[tschak909]

@dom - looks like the WORK buffer can use anywhere from 8 (for transforming a single generator) to 203 bytes (for transforming an entire mobile object in Mode 2).

the sprite table entries can be up to 32 bytes each.

(I am still rev-enging OS7, but I might as well get those questions answered.)

-Thom

[DavidLetson]

Thanks!

[tschak909]

@dom can we do user-set sizes for those areas?
-Thom

[dom]

I've just added the following:

Code: Select all

// -pragma-define:CRT_COLECO_SPRITE_NAME_SIZE=nn
// -pragma-define:CRT_COLECO_SPRITE_ORDER_SIZE=nn
// -pragma-define:CRT_COLECO_BIOS_BUFFER_SIZE=nn
// -pragma-define:CRT_COLECO_BIOS_CONTROLLER_SIZE=nn

You can access them from code by including <arch/coleco.h> - they're just exposed as uint8_t arrays at the moment.

If you come up with better names for the pragmas let me know - I'm not wedded to them!

[tschak909]

Thank you, good sir.