OSDK 1.21

[waskol]

I think it won't work, damned.
Because I'm not a genius I Dinamically linked the f***ing runtime, that's why my exe is small instead of statically linking (wich was my initial compiler config).
There are no way nowadays to make things small.

statically linked is 1M, not less, and it will work for sure :
https://workupload.com/file/8KUv75QZ67f

sorry pals

[ibisum]

Yes, I’ll try this out tomorrow @Dbug and will report in. Should be noted however that I’m also using WINE in my scenario, in case that’s an issue - but it hasn’t been before. Anyway, will try things out - stay tuned…

[Dbug]

An alternative is to try this version of header.exe which takes an additional optional parameter with the name

header.zip

(182.06 KiB) Downloaded 63 times

and then modify the script from

Code: Select all

%OSDKB%\header.exe %OSDKHEAD% build\final.out build\%OSDKNAME%.tap %OSDKADDR% 
%OSDKB%\taptap.exe ren build\%OSDKNAME%.tap %OSDKTAPNAME% 0

to

Code: Select all

%OSDKB%\header.exe %OSDKHEAD% build\final.out build\%OSDKNAME%.tap %OSDKADDR% %OSDKTAPNAME%

I know taptap does plenty of things, but in the case of the OSDK build script it's just to provide the name in the tape header.

[iss]

Ups, in my prev. post I'm talking about option '-n' for 'header.exe' utility which obviously is not present in the original source.

Attached is my modified version (which I'm using so long that forgot about the changes I've made).

@Dbug: if you don't mind merge it to osdk ? (btw, some source formatting is needed).

[Dbug]

@Dbug: if you don't mind merge it to osdk ? (btw, some source formatting is needed).

What's the reason for the -3/-4

[iss]

@Dbug: if you don't mind merge it to osdk ? (btw, some source formatting is needed).

What's the reason for the -3/-4

The reason was that a tool (or emulator ? I can't remember ) was working only with exact number of 0x16 sych bytes.

[Dbug]

Ok, new version, this type with iss patch

header.zip

(182.27 KiB) Downloaded 67 times

To use it replace

Code: Select all

%OSDKB%\header.exe %OSDKHEAD% build\final.out build\%OSDKNAME%.tap %OSDKADDR% 
%OSDKB%\taptap.exe ren build\%OSDKNAME%.tap %OSDKTAPNAME% 0

by

Code: Select all

%OSDKB%\header.exe -n%OSDKTAPNAME% %OSDKHEAD% build\final.out build\%OSDKNAME%.tap %OSDKADDR% 

[iss]

There are no way nowadays to make things small.

This is not quite correct .
I our case - supporting utility as part of a toolchain - best is to use scripts.
And when we talking about adding TAP header to binary file this is my 'oheader.lua':

Code: Select all

#!/usr/bin/env lua
-- --------------------------
--              _          --
--  ___ ___ _ _|_|___ ___  --
-- |  _| .'|_'_| |_ -|_ -| --
-- |_| |__,|_,_|_|___|___| --
--    iss@raxiss (c) 2025  --
-- --------------------------
-- add tap header to binary
-- usage: oheader <binary> <start address> [0=no-autorun [INTERNAL NAME]]
--

-- print(arg[0],arg[1],arg[2],arg[3],arg[4])

local n = arg[4] or ''
local s = tonumber(assert(arg[2]))
local f = assert(arg[1])
f = assert(io.open(f,'r'))
local bin = f:read('a')
f:close()
--
f = assert(io.open(arg[1]:gsub('%.bin$','')..'.tap','w'))
f:write(string.format('\x16\x16\x16\x16\x24\x00\x00\x80'))
f:write(string.format((arg[3] and arg[3] == '0' and '\x00') or '\xc7'))
f:write(string.char((s+#bin)>>8))
f:write(string.char((s+#bin)%256))
f:write(string.char(s>>8))
f:write(string.char(s%256))
f:write(string.format('\x00%s\x00',n))
f:write(bin)
f:close()

... not very big and can be 'optimized' lot.
The real benefit: small, portable (it's proven to work "as is" on Linux,Windows,macOS), easy to be fixed.
Actually in my toolchain all such required tools are written in Lua (I like Lua!) but of course Python will do the job too.
Anyway, just talk...

[waskol]

Because it's in c and that the runtimes are provided by the subsystem
lua has a runtime too (the interpreter).
pascal object is standalone, and it's damned fast in its execution, like c can be
We can't have it all.

[Dbug]

Because it's in c and that the runtimes are provided by the subsystem

That's not actually correct: All the executables in the OSDK are 32bit statically linked, they don't depend on an external C runtime which is why they run on most version of Windows (32bit or 64bit) and have been running fine on Wine as well for quite a few decades (time flies!)

If they were dynamically linked, they would be much smaller, but you would have to install the proper version of the C runtime.