https://www.omnimaga.org/asm-language/8384-free-ram-areas/
May also be helpful.

Splitting your code into subprograms is helpful. You could have one subprogram that defines variables/sprites, one subprogram that runs the game, one that contains subroutines to render the game, etc, and of course the "main" program which sets everything up.

I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.

Actually there is enough free ram for 5 buffers. (Although a game i made used 6).
Take a look at this, a modified version of @Runer112's greylib:
L6->Str1B1
L3->Str1B2
L1->Str1B5
L2+103->Str1B3
L4-512->Str1B4
|E36->^^oGP
#ExprOff
Lbl GTUNE
1->K
ClrDraw^^r^^r
Rect(24,0,24,64)^^r
Rect(72,0,24,64)^^r
Rect(48,0,48,64)
Text(0,,"GREYSCALE RATE "[CF]"/"[0500]
GDISP()
While 1
Text(80,0,{Str1RATE}>Dec
Copy(L6,L3,168
GDISP()
If getKey(2)
{Str1RATE}--
Pause 50
1->K
ElseIf getKey(3)
{Str1RATE}++
Pause 50
1->K
ElseIf getKey(15)??getKey(41)??getKey(9)??getKey(54)
!If K
Return
End
Else
0->K
End
End
Return
Lbl GLOAD
Asm(3E40D3(^^oGP)^^r)
fnInt(GI, and 0)
Return
Lbl GUNLOAD
FnOff
Asm(EF204AAF32178DEF1150)
Asm(AFD3(^^oGP)^^r)
LnReg^^r
Asm(FF)
Return
#ExprOn
Lbl GDISP
FnOff
Copy(Str1B1,Str1B3)
Copy(Str1B2,Str1B4)
FnOn
Return
#ExprOff
Lbl GNOT83
Asm(DB0217ED62)
Return
#ExprOn
Lbl GI
If {Str1GNOT83}Asm(7DDEF6D303)
Asm(3E02D3(^^oGP+1)^^r3A(Str1RATE)D3(^^oGP+2)^^r
Else
Str1GI
{}--
ReturnIf ->{}
{Str1RATE}->{Str1GI}
End
DispGraph(Str1B3,Str1B4)^^r^^r
ReturnL6 and L3 are still used for drawing while L2+103 and L4-512 are used for the greyscale. "Lbl GTUNE" is" the greyscale tuner, "Lbl GLOAD" initializes the greyscale (use this at start of program), "Lbl GUNLOAD" uninitilizes it (use this at end), "Lbl GDISP" flips the buffers (use this when you finish drawing your frame), "Lbl GNOT83" returns if or not the calc is an not 83, and lastly "Lbl GI" is the actual interrupt.

"Str1RATE" is a pointer to the greyscale rate, a single byte that tells how often the greyscale should update. "Str1GI" is a pointer to another byte that acts like a counter of sorts.You should ask @Runer112 for more info, I have forgot the intricacies of greyscale

I built a prototype for a z80 computer that uses an arduino for communication and bootstrapping. I can assemble a z80 source program with brass, and send it to the arduino with a small python program. The arduino is running a firmware program that waits for a program to be sent over serial, which it loads into the ram chip for the z80 to execute. The z80 communicates with the arduino via IO requests. The arduino<-->z80 API only contains 3 commands, but these can be used for the z80 to send messages to the PC via serial.

This is a small test program to send "test1" and "12345" to the PC via serial:
#define output(x, y) ld a,y \ out (x),a
#define command(x) output(PORT_COMMAND, x)
 output(PORT_ADD_LOW, writeTo & FFh)
 output(PORT_ADD_HIGH, writeTo >> 8) ;set data act-on address to writeTo
 ld hl,string1
 ld de,writeTo
 ld bc,6
 ldir ;copy string1 to writeTo
 command(COMMAND_WRITE_SERIEL) ;tell arduino to send data from act-on address to PC
 ;stuff
 ld hl,string2
 ld de,writeTo
 ld bc,6
 ldir ;copy string2 to writeTo
 command(COMMAND_WRITE_SERIEL) ;tell arduino to send data from act-on address to PC
 jr $ ;do nothing
string1:
 .db "test1",0
string2:
 .db "12345",0
writeTo:

Picture:


Todo:

Use external clock. (Currently arduino is generating a clock signal)
Upgrade to 128kb ram chip. (Currently i am using a 32kb one)
Make arduino use pin registers for control signal IO. (minor)
Make a paging circuit for said ram chip.
Add an LCD
Write an OS(?)
Add an SD card(?)
Make PCB (?)

 I got bored so i started programming an engine for open world RPGs. (In c++ with openGL 2). The world is split into "cells"/"chunks" which are loaded/removed as you move around. Alpha-mapping is used to shade different ground textures onto the ground mesh. (the ground is a mesh, not a hightmap, to allow for more freedom.) I am also programming some sort of "construction set", which currently allows you to edit some values of the cell, adding/removing/manipulating prefabricated objects in the cell, and a utility to paint textures onto the ground.

Prefabs will range from things like rocks on the ground, to entire dungeons.

Progress:
Terrain rendering / resource management- mostly done.
Prefab rendering/manipulation - started
loading .ini files - need to start
construction set - lots of tedious work needs to still be done, but its not necessarily hard;
proper saveing/loading of cell data.
Resource manager for materials/textures/prefabs - started;
lighting - light is magical right?
physics - some progress, mostly on hold for now.

things that need to be done in feature that i haven't thought about yet:
Entity system.
Actual RPG elements like questing, etc.
Event Scripts.
Mesh editor (?!)

Pictures:

This is how the construction set looks so far: The ground repeats like that becomes i am too lazy to make proper terrain, so i just made it repeat.

Texturing the ground: (In this case removing textures.):

Added a prefab (that pink thing) to the cell: (as well as some texturing to the alpha map).

This is awesome! It should be really great since I know that people with CSEs would always complain when monochrome games didn't work (usually new users), so this should help the CE crowd not follow the same ordeal.
Speaking of, someone should make this for CSE

* 123outerme runs

Thanks!
I could (and will) release the code, but unfortunately i dont think there would be anyone to port it to the CSE

Quote from: E37 on June 15, 2017, 06:23:07 pm

Quote from: Runer112 on June 13, 2017, 06:06:28 pm

The axiom Fullrene should allow you to bypass the 8KB program code limit. There are mixed reports of its efficacy, though. Also, the program needs to be launched from a shell, as the OS simply refuses to launch programs this large.

Alternatively, compile your code as an application to get a bit under 16KB of room, although this may not be desirable for other reasons.

Interrupts being enabled or not should have no bearing on this.

Fullrene uses interrupts to disable the limit. If you read the source, you will see that it uses the I register for interrupts. I know that zStart has a hack to disable the limit, but I don't know if it simply removes the limit firm the OS itself. I don't know about crabcake. I couldn't find a download for it anywhere. Compiling as an app is not an option for me currently for various reasons.

It uses the i register as part of the logic to disable the code limit, but it does use interrupts or the i register after that. The limit is not removed permanently; it is only removed for the remainder of the program's execution.

I thought it sent some magical number to some magical port? I remember a really old news article about this by 'thepenguin' (?).