This is making coding with EDASS 128 even more fun and easier.
And you have BASIC area free { as much as EDASS 128 is allowing that with default settings }
Anyway, with 12'000 bytes free a lot of things can be achieved, especially when you still have the
access to all assembly routines available in ROM { BANK 15 } and don't need to waste time or use memory to write your own functions.
Do not use Graphic commands because that is moving the BASIC working area to $4000 to reserve the previous BASIC area for the high resolution screen { $2000 $ 4000 } and from $1C00, 1000 bytes are reserved to be Graphic color area... Ergo, $1c00 or dec, 7168 is first color cell 8 { bytes in size }.
Which means your free memory is gone, because just a little above $4000 EDASS 128 itself is doing what has to be done!
Keep in mind that EDASS 128 is also in the area from $1a00 to $1bff.
That's why you have only between $1300 and $19ff available for your code.
All is said...
{ next step is to squeeze SFK in a region where your free memory can be extended and
usage of the graphic screen possible }
Give it a go now, it's fun to learn coding in assembler for C128!
Update, 14.04.2024 - You do something and then you have a feeling it could be more optimized. Well, that is one of such cases {SFK21, BLOAD"SFK21.BL", SYS 15100, need less memory}
{Main goal is to place it somewhere below
$e00 and have free from $1300 to $19ff and free from $1c00 to $4000, meaning hires graphic can be used. It is a work in progress {WIP}}
Update, 14.04.2024 - This is now finished version of SFK21A1.
Made using EDASS 128 for EDASS 128, read ReadMe.txt file.
Where SFK21A3 is located : { update 21.04.2024, revision A1 was causing problems! }
$0800 - $09ff BASIC stack area { means you can't write BASIC programms }
$0b00 - $0dff Tape/Serial device {nobody is using those nowadays }
Where you can write your part:
$0e00 - $0fff { if no sprites are used }
$1300 - $19ff { free area, usually until $1c00, but EDASS is inbetween now, $1a00 - $1bff }
$1c00 - $4000 { from $4000 Edass is located}
Well, considering the fact it's BANK 15 with full access to BASIC assembly routines, you can say that having the access to more than 12'000 bytes, all the C128 assembly goodies, free Sprite area and all that with installed EDASS 128 Editor & Assembler, this isn't a bad deal at all because working without
SFK is real pain in the butt.
And now i can finally go back to work on TileEditor TED2.0!
It's time to have it done now that more memory is available.
First major change is that editor design is loaded incl. color map and sprites.
My idea behind that is to save the memory in not using the built-in design and second advantage is:
You'll be able to create your own editor designes within the given freedom.
You can actually modify everthing, incl. sprites!
{But i wouldn't do that. They're needed by the editor}
The size of the code was further reduced, but probably more can be done.
.png){kind=small}
TED 2.0 is still a work in progress, but you can use it for demo of TED 2.0 and practice a little bit.
Attached is a small instruction page of how to use it.
Picture 2 is showing one example of how it can this interface look.
First time loading is also loading an example, just to show where you can draw.
The centered TED 2.0 editor part will be deleted. No point in drawing there.
You can use everything BASIC Editor is offering to draw, meaning all its graphic elements.
Also color ram is saved.
Meaning you can use all colors available with Control/Commodore keys.
Demo interface is loaded just once.
In case you want to see it again, you can start like this.
{press RUN/STOP Restore before to avoid issues because this application is interrupt driven}
poke 8193,1: sys 8192
This will load the example interface.
In fact, you can create your own example interface {no diff colors} if you rename e.g. 01GFX.BL to
DEMOGFX.BL {you need to scratch the existing DEMOGFX.BL file first}
poke 8195,1: sys 8192
Will show you the text message.
Also note, DesEditor is located in $2000 area.
If you use SPRDEF command or Graphic commands with delete activated, e.g. Graphic 1,1,
DesEditor will be deleted and you need to load it again.
{Future version might be relocated, but for now this is it}
Find attached US Positional Keyboard i am using with VICE 3.7 and see where the needed
ALT key {to save button} is located in case you are not working on real Commodore C128.
BEFORE you start this demo, type following in BASIC direct mode:
graphic 1:graphic 0
then bload the 3 parts from the floppy and type sys 4864 to start. {sorry for any inconvenience}
While this project is ongoing i see why were people already back then programming NOT using the actual 8-bit computer they were programming for, but instead they were doing that using some XY computer. Some kind of Cross-Assembler without Emulation because the workstation was connected with the 8-bit computer via cable to test the application, games or whatever it was.
Back then it wasn't any different than nowadays in terms of memory on 8-bit computers.
-
Somehow i prefer native coding, directly on the host {emulation in this case}, which brings us to the actual problem: never enough free memory with installed assembly environment and SFK!
-
At the moment i am literally having around 300 bytes free memory to finish TED 2.0, hahaha, easy!
Past days i was working on finding a solution for the following question:
Where to put my *code and free the 9KB high resolution space {needed for tiles!}???
*that was located before from $2000 which is graphic area.
-
Wasn't a piece of cake, but it could be managed. I had to rewrite a few things to reuse the subroutines, meaning they are now having double functions. 1st call do A, 2nd call do B. 3rd call do A again. That saved a few bytes!
-
Anyway, hopefully i can squeeze the rest in mentioned 300 bytes. And if not, well, i'll have to see if i can reduce the code even more, but with my assembler skills {started learning in November 2023, now it is May 2024} that's connected with a lot of sweating! HAHAHA!
-
Update - 07.05.2024 - I actually needed less than 300 bytes, still approx. 170 to go. I bet in 1 year i can do the same TED 2.0 just using 300 bytes haha...
This was a great experience in learning C128 assembly language. Close to four dacades ago, this was unimaginable, but here i am now.
Only remaining thing is to save the work. And as always, i was wondering what's the best way to do it and are the remaining bytes equal to 'oh, that was close' or more 'oh shit, not more bytes free' hehehe...
Well, i'll just give it a go and we will see then, however, i see already, it will be necessary to rethink few past aproaches and optimize it once more.
If you think, that's the worst part!?
No, it's not. Testing is the worst part... A nightmare hahaha...
I added a disk so you can test it.
I am using VICE 3.7. USA positional Keyboard where ALT is located under F11 on PC Keyboard.
Other emulators might have ALT somewhere else!
{e.g. CloantoC64Forever is using Windows ALT key as Commodore ALT key }
VICE version 3.7 and latest VICE version 3.8 - VICE 3.8 killed everything!!! Update 10.05.2024 - now even Vice 3.1 isn't working!
11.05.2024 - UPDATE!
{ seems like i was my mistake, but who like to blame himself, hehe }
I noticed that VICE version 3.8 is out since a while and give it a go.
First thing was a message in regard of unsupported .ini file and it could cause problems.
Could cause, doesn't necessary mean it will, right {I learned it actually means exactly that, hehe}
it deadly & clearly means DO NOT INSTALL!
Well, too late, i installed it anyway...
I used that version 3.8 like 2h and i don't immediately test everything, but just if it working and not crashing and i do save it different revision to be able to go back.
AND DISASTER, today i wanted to continue on the latest revision 5 and it didn't work.
I went back to latest 5 revisions. Nothing is working.
Hell, not even the yesterday tested and fine working demo, IS NOT WORKING ANYMORE.
Not under 3.7 and also not under 3.8. WHAT!!!
Installation of VICE 3.8 was clearly a mistake. It trashed not only 3.7, everying i did, not even 3.8 is working... haha... What a wonderful day!
Yes, it can be called shit!
I have no nerves to bother with that now.
After trying on VICE 3.1, demo was working....
So, Vice 3.8 really messed up 3.7 and itself haha...
UPDATE - 10.05.2024, 22:30 - Nothing i didn't tried, nothing i achieved, nothing is working!
Not even previously working 3.1 is working now and as you can see in the 3rd screenshot, it's now exactly the same error message. And i didn't touched the 3.1 folder!
Seem like this 3.8 was a bad idea... Now i don't have an environment and can't continue...
Wondering what exactly went wrong because as you can see below, graphic is working under 3.8.
But why it worked on 3.1 today and now also no with the same error message as under Vice 3.8!
BONUS Edass 128 .d64 Floppy - AND THAT'S A GOOD ONE!
Not under VICE 3.7 and not under Vice 3.8 {see previous entry}
I can't explain it right now, but i wanted to see if VICE version 3.8 is shit or useful.
Result is this Bonus .d64 Floppy with some sprites, source codes, examples and explainations...
Learning assembly? Then this is for you.
Btw. i didn't activate FAST in example 3 on purpose while loading files.
That's why you can see what's going on. You can enable it in source code if you want.
I did disabled LOADING/SEARCHING messages not to disturb the screen content.
-
Except the REU code part, this .64 Floppy was created by me, incl. sprites etc.
I gave a credit in source code for REU accordingly. { http://commodore128.mirkosoft.sk }
REU was from my side slightly modified to do what i need it to do {i will surely play with that a little bit more AFTER i fix VICE problems! {RESOLVED!}
As mentioned...
Part of the examples is also a possibility to use REU to transfer screens to REU memory.
I can imagine like using it to load and transfer levels. No need to use internal C128 memory and no need to load files again. Plenty of room is available on REU.
The transfer is done from the screen memory directly to REU memory.
128KB REU is what i have *activated. That's 8x 16'000 bytes {1 screen is 1000 bytes}
* Important: In order to test this REU example, please activate REU in VICE first!
Now i obviously have all Emulators with the same "NO GRAPHIC AREA" message...
Well, i guess not everyone is so lucky, hahaha!
We have a following situation where 4 are wrong and 1 is right { that's me ;-) }
That's means i did a mistake somewhere and dragged it without noticing it to all the latest revisions.
Even in Demo? BUT WHY was it okay once yesterday and during demo creation...
WHY WHY WHY?
---------------------
Few moments later... {11:35, 11.05.2024}
It crossed my mind what if GRAPHIC AREA really isn't activated and why it was working all the time even if it shouldn't have in latest revisions, including demo?
It seems like i did activate the GRAPHIC AREA, however, in BASIC with the GRAPHIC 1,0 command.
And that little fellow remains active, until you actually say GRAPHIC CLR {that is setting the pointers back to standard}.
I had that active and therefore the mistake i was dragging with me wasn't noticed.
How it could be noticed as a bug when it was working!?
So glad i have it solved :-)
{not completelly, need to see the assembly code, but now i know what to look for...}, {...done!}
People, this was very educational and even if i am probably the only guy on this pages talking to myself i hope "we" learned something nevertheless, hehe...
-
lda #$00 ;transfer size
sta tsize ;1000 bytes
lda #$10 ;
sta tsize+1 ;
lda #$91 ;read & transfer
sta command
rts
-
This was unfortunatelly sold as $1000 bytes, but it isn't 1000, it's 4096 bytes.
{I corrected all this in newest REU example where you can transfer the whole 1000 bytes screen and color map data. And with 1000 bytes i really mean 1000 bytes or $0400, and sure not $1000}
-
Anyway, as said: noticed, corrected and updated the .64 BonusFloppy in correcting the content and also adding Example 5 which is transferring screen data from $0400 and color data from $d800 and of course, complete Edass 128 sources are included for better understanding and maybe you'll start with C128 assembly programming too!