This version of loader works well

[jbperin]

Hi all,

I recently faced severe difficulties with the loader.asm that comes with osdk_1_20\sample\floppybuilder

I was trying to use it to load some textures pack when player change area in the game scene.

And the texture was half split then reverted and then started to vanish. It was very strange.

I turned to the loader available here:

https://github.com/Oric-Software-Development-Kit/Oric-Software/tree/master/users/dbug/UpgradeTime/Encounter/FloppyBuilderVersion/code

And then it started working nicely.

Some graphics from Project Utumno imported into Castoric:

creatures.gif (406.58 KiB) Viewed 5382 times

This loader is great !!

[ibisum]

Drool!

Looks great. Can't wait to see how far you take this ..

[Chema]

Amazing!

[jbperin]

Looks great. Can't wait to see how far you take this ..

I myself wonder how long the Oric will accept me to put some code in its memory.

The next step is to add a shooting system to destroy the monster that prevents me from reaching the princess.

It should look like that (in less buggy):

shootMonster.gif (125.66 KiB) Viewed 5212 times

Amazing!

Thank you. Both for this kind word and for the code that I use which comes from you (in keyboard handling and disk loader).
Dbug loves to say that we are sitting on giant's shoulders.

[Dbug]

Dbug loves to say that we are sitting on giant's shoulders.

Technically you don't have to sit. You could be standing, crouching, jumping, etc... just make sure the giant does not get annoyed

[jbperin]

Hi all,

I plan to use the floppy builder and loader in order to get 16k more memory for my next software.

But I'm facing a severe issue with the floppy loader mecanism on ORIC that I can't overcome.

The attached archive demonstrate the issue I'm facing.

It is a program that only loads the standard BASIC screen (@ $BB80) with the appropriate charset to display it (@ $B400).

Code: Select all

void gameInit(void){
    LoadFileAt(BASIC_SCREEN, 0xBB80);
    LoadFileAt(LOADER_CHARSET_STANDARD, 0xb400);
}

void gamePulse(void){
}

When I build and run the project with commands:

Code: Select all

osdk_build.bat && osdk_execute.bat

I can see on screen and in memory that the loading works nicely.

But when I try to transition to a better version of the floppy loader that I located in directory RomlessGame\code\loader.
It fails .. And I can't understand why

for example, If I copy files from RomlessGame\code\loader\fromMiJuego into RomlessGame\code\loader to replace the builder used during build,
I cannot find my basic screen in memory.
As thought it is not loaded .

Can anyone help me understand what's wrong with my code ?


I used to use the loader provided with the OSDK .. and I made several prototypes with it.
But when I started using it intensively for MiJuego, I realized it was somewhat buggy and then I decided to take a better version.

I found that Dbug uses his own adaptation of the floppy thing from Chema's Blake 7 in Encounter and I decided to use this more recent version.

I managed to make MiJuego with this "new" version.

But now I'm trying to use the floppy thing on a blank new Romless project .. and I'm blocked by this misunderstanding.

Please Help If You Can.

[jbperin]

The problem was coming from the file code/overlay.s where I define where are going to be loaded lookup tables and textures in high memory

I had to change:

Code: Select all

; raytables.bin 4437 octets
* = $ED95

into:

Code: Select all

; raytables.bin 4437 octets
; TODO . should be * = $ED95
* = $EC00

I don't know why .. I presume it is address conflict with the loader or something like that.

I put that in the box "Things I should try to understand but I'm going to try to live without understanding it".

[Dbug]

Well, you could add some conditional check in your overlay file that the address does not overlap after FLOPPY_LOADER_ADDRESS.

In loader.asm there are quite a few checks like that:

Code: Select all

#if ( _Vectors <> $FFDE )
#error - Vector address is incorrect, loader will crash
#else

So at the end of overlay.s you could have something like:

Code: Select all

#if (* > FLOPPY_LOADER_ADDRESS)
#error - Overlay file is overwriting the loader
#else

[Chema]

Memmap is a great utility to show where things may overlap, as soon as you define labels for each section.

https://www.osdk.org/index.php?page=doc ... age=memmap

[jbperin]

So at the end of overlay.s you could have something like:

Code: Select all

#if (* > FLOPPY_LOADER_ADDRESS)
#error - Overlay file is overwriting the loader
#else

I tried to add the following lines at the end of the overlay.s file :

Code: Select all

#if (* > FLOPPY_LOADER_ADDRESS)
#error - Overlay file is overwriting the loader
#endif

And I got the following error message:

Code: Select all

Assembling
#error - Overlay file is overwriting the loader
C:\Users\jbperin\Documents\RomlessGame\code\overlay.s(50):  fd55:Syntax error
Break after 1 errors
ERROR : Build failed.

For information, $fd55 looks like the osdk_stack in my case .. (look below)

Memmap is a great utility to show where things may overlap, as soon as you define labels for each section.

https://www.osdk.org/index.php?page=doc ... age=memmap

Yes I use it quiet often through the osdk_showmap.bat script in order to evaluate how much memory I use.
I even used it to calculate the adress I could put my lookup tables at.

Here's the end of the overlay memory mapping:

Code: Select all

$ec00	64	64	_multi120_low
$ec40	64	64	_multi120_high
 ... SOME NUMEROUS LOOKUP TABLES  ....
$fc55	256	256	_tab_1overcos
$fd55	256	256	osdk_stack
$fe55	4	4	osdk_check
$fe59	403	403	osdk_end
$ffec	3	3	_LoaderApiSaveData
$ffef	1	1	_LoaderApiFileStartSector
$fff0	1	1	_LoaderApiFileStartTrack
$fff1	1	1	_LoaderApiFileSize, _LoaderApiFileSizeLow
$fff2	1	1	_LoaderApiFileSizeHigh
$fff3	1	1	_LoaderApiJump
$fff4	1	1	_LoaderApiAddress, _LoaderApiAddressLow
$fff5	1	1	_LoaderApiAddressHigh
$fff6	1	1	_LoaderFDCRegisterOffset
$fff7	8	8	_LoaderApiLoadFile

I really don't understand how the loader could fit between $ffec and $fffa
It is as if symbols of the loader was not all visible in the memory mapping.
I don't understand

I know my lookup tables is 4437 bytes long (i.e. 0xfd55-0xec00)
So, at first I had naïvely substracted 4437 to the adress of the first loader symbol (i.e. _LoaderApiSaveData at $ffec) and substracted the size of osdk_stack and pointers .. to reach the value $ED95
But It was badly crashing .. so I started decrease the adress more and more ..
It started working around $EC00 .. So I set $EC00 and than decided not to change any more.
I'm sure I'm losing some bytes here.


Moreover, I don't understand why, when I'm building a DSK with OSDK, I have to manually copy the symbol file to the %OSDK%\Oricutron directory if I want symbols to match the real memory mapping.
There seems to be several passes when elaborating a .DSK from various .TAP and the symbol that is used looks like an intermediate one .. or something like that.

If someone has a clue about that .. I would love to read it.

[Chema]

I am not sure if I'll be able to clear things up. Dbug is who made the tool. In my sources the loader code starts at $fd00, not at the usual $fe00, because I added the saving routine and some other things. If osdk_end is greater than that value, you run into trouble.

From $ffce up what you have is just labels with data and API entry points, so they are just a jmp <address> to the location of the corresponding routine.

And, yes, the build is done in several passes. Not sure what to answer to your other questions... I may re-read them later (I am at my phone now) and see if I can help.

[Dbug]

The reason why you don't have the symbols for the loader is because the loader is not built at the same time, it's two different executables and what you see if just the "loading api" which is at the end of the program.

For Encounter I modified my build script to save the loader symbols and glue them to the main program symbols:

Code: Select all

%osdk%\bin\xa -DASSEMBLER=XA -DFREQUENCY_%FREQUENCY% -DDISPLAYINFO=%DISPLAYINFO% loader.asm -o ..\build\files\loader.o -l ..\build\symbols_Loader
(...)
copy build\symbols+..\build\symbols_Loader ..\build\symbols_GameProgram >NUL
(...)
%osdk%\bin\MemMap.exe -s30 build\symbols_GameProgram build\map_game.htm Game %OSDK%\documentation\documentation.css
explorer build\map_game.htm

[jbperin]

the loader code starts at $fd00

OK thank you very much for this information.

It will allow me to tune a bit more accurately my memory usage in this area.

For Encounter I modified my build script to save the loader symbols and glue them to the main program symbols:

Hey .. That's interesting. I will try to apply the same in my project.
Thank you

[Chema]

The loader address is stared in the floppybuilderscript.txt file. Here is my code in Blake's 7:

Code: Select all

;
; Now here is the loader code, that one is Microdisc only
;
SetPosition 0 4
WriteLoader ..\build\files\loader.o $fd00 ;$fe00 		; Sector 4

I am sure it ends up in floppy_description.h as the defined tag FLOPPY_LOADER_ADDRESS

[jbperin]

I am sure it ends up in floppy_description.h as the defined tag FLOPPY_LOADER_ADDRESS

Oups .. indeed .. I could have figured it out if I had inspected more carefully the generated file.

I indeed have:

Code: Select all

#define FLOPPY_LOADER_ADDRESS 64768   // Address where the loader is loaded on boot ($fd00)

in my generated floppy_description.h

Thanks a lot !!