Hello all,
There seems to be a surge of interest in Dusk OS these days and I get asked for
tutorials. My naive reaction to this is to ask what's wrong with the docs as
they are. The naive response is to say that there's no way around it: Dusk is
operated, not used.
But one has to face it: significant effort has to be poured in learning about
Forth and Dusk and the payoff is uncertain before that cost is paid. One could
decide to pay this upfront cost based on the advertised features alone, but
some people need to see the miracles with their own eyes before believing them.
I can't blame them, I might do the same myself.
To this end, I began writing the Dusk Tour[1], a series of annotated commands
designed to be ran in dusk-sdl without prior Forth or Dusk knowlege. The idea
is that we don't explain stuff, only show.
So far, I only have assembling and compiling covered, but I'm also planning to
add a significant part for graphical wonders.
The uxn/varvara rewrite enticed me to essentially rewrite the whole graphical
stack and that thing is getting quite pretty. And I think it will be fast. I'm
thinking that a tour of that stack might turn in a few people into believers.
Onwards,
Virgil
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/tour.txt
Ok I made it to the end! This is excellent.
(I just took a while to figure out how to build dusk-curses. usermode/README.md. Perhaps the section `Build and run` should come before `Packages`? It doesn't seem necessary to understand packages. And the sections before and after the build section both mention packages, which suggests they may be better off being contiguous..)
(I haven't tried the multilib thing for dusk-sdl yet.)
Just wow!
After getting Dusk OS running on the A64-OLinuXino from Olimex I
experimented some. I tried the starting guide from Alex Wennerberg, but
got stuck on the third command:
$ curpath :listdir
It seems that this has changed between versions? Tried to find another
starting point for someone who's familiar with programming and how
computers start executing code, but not with Forth and the nitty gritty
details. Didn't find one, but at the moment the information about this
project seems to be scattered in a few places. Was thinking about the
Wiki function which sourcehut seems to have. But then another project
needed attention.
That is finished and when I came back here, I saw this. Good news for me
and hopefully this will get me started. I'm rally interested in Collapse
OS and that is now hosted in Dusk OS. So the learning curve seems to be
steep. But I think in the end I will have learned something and
hopefully got ideas for my "dead" computer project.
Thanks!
--
Henk van de Kamer
https://www.vandekamer.com/https://www.hetlab.tk/
On Sun, Sep 15, 2024 at 11:38:28AM +0200, Henk van de Kamer wrote:
> Just wow!> > After getting Dusk OS running on the A64-OLinuXino from Olimex I> experimented some. I tried the starting guide from Alex Wennerberg, but got> stuck on the third command:> > $ curpath :listdir> > It seems that this has changed between versions? Tried to find another> starting point for someone who's familiar with programming and how computers> start executing code, but not with Forth and the nitty gritty details.> Didn't find one, but at the moment the information about this project seems> to be scattered in a few places. Was thinking about the Wiki function which> sourcehut seems to have. But then another project needed attention.> > That is finished and when I came back here, I saw this. Good news for me and> hopefully this will get me started. I'm rally interested in Collapse OS and> that is now hosted in Dusk OS. So the learning curve seems to be steep. But> I think in the end I will have learned something and hopefully got ideas for> my "dead" computer project.> > Thanks!> > -- > Henk van de Kamer> https://www.vandekamer.com/> https://www.hetlab.tk/
Hello Henk,
The filesystem API indeed changed since Alex wrote this tutorial, which means
it's broken. ":listdir" became "listdir" and the concept of "current path" was
removed. You can, if you want, create yourself a "curpath" variable and use that
value in "lookuprel"[1], but there is no Dusk-sanctioned way to do it, you just
bootstrap your own.
But Dusk being a memory oriented system, FS accesses are really much less
important than in UNIXes. You want to keep track of memory addresses much more
than you want to keep track of FS paths.
Yes, Dusk changes a lot and one of the unfortunate side effects is to break
tutorials like this. But one of the great joys of working on this project is to
not let myself be burdened by past choices when comes the time to face
expanding specifications. Refactoring such a system into something tighter is a
gargantuan, black mamba like, dopamine shot.
That being said, things *are* stabilizing with time. Shaking things around to
allow pieces to fall into place can only be done so much. After a while, things
can be considered "tight". Namespace removal[2] was the biggest shaking I did
since the "wildly changing all the time" early times of Dusk. I was heavily
invested in the namespace concept and it took me a while to notice the
drawbacks. Once I saw them, I had to "divest" fast with a painful change that
oddly looked liked idle and aimless change. I hope I don't have another one like
that coming.
It doesn't feel this way. The HAL is tight, Big Moustache feels tight, "unit
bubbling", which replaced namespaces, feels tight.
Regards,
Virgil
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/fs/core.txt#L246
[2]: the ":listdir" to "listdir" change
On Wed, Sep 11, 2024 at 03:25:22PM -0400, Virgil Dupras wrote:
> Hello all,> > There seems to be a surge of interest in Dusk OS these days and I get asked for> tutorials. My naive reaction to this is to ask what's wrong with the docs as> they are. The naive response is to say that there's no way around it: Dusk is> operated, not used.> > But one has to face it: significant effort has to be poured in learning about> Forth and Dusk and the payoff is uncertain before that cost is paid. One could> decide to pay this upfront cost based on the advertised features alone, but> some people need to see the miracles with their own eyes before believing them.> I can't blame them, I might do the same myself.> > To this end, I began writing the Dusk Tour[1], a series of annotated commands> designed to be ran in dusk-sdl without prior Forth or Dusk knowlege. The idea> is that we don't explain stuff, only show.> > So far, I only have assembling and compiling covered, but I'm also planning to> add a significant part for graphical wonders.> > The uxn/varvara rewrite enticed me to essentially rewrite the whole graphical> stack and that thing is getting quite pretty. And I think it will be fast. I'm> thinking that a tour of that stack might turn in a few people into believers.> > Onwards,> Virgil> > [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/tour.txt
I've just added a graphical part to the tour. Short but, I think, sweet.
Hi,
> (I just took a while to figure out how to build dusk-curses.> usermode/README.md. Perhaps the section `Build and run` should come> before `Packages`? It doesn't seem necessary to understand packages.> And the sections before and after the build section both mention> packages, which suggests they may be better off being contiguous..)> > (I haven't tried the multilib thing for dusk-sdl yet.)
It took me two hours to figure out how this is done in Debian 12
(Bookworm). I created a patch against the README.md in the hope it can
be used as overview how this is done. In the past I used similar
examples from other distros to get things building in Debian.
May be it would be better to separate the build instructions in a new
document, so detailed instructions for other distros can be added.
Anyway, I've now done the tour and it is good to see things working,
even if it is still not clear to me why it works :-).
I'm the author since april 1998 of a three page column called Het Lab --
the lab -- in a Dutch computermagazine PC-Active. I've learned what
people need to reproduce my work and most of the time that is a lot more
of details you skip over because of how many words fits on a page. I'll
probably propose some articles when I figured out what is my goal: using
Collapse OS which is now hidden somewhere in Dusk OS.
--
Henk van de Kamer
https://www.vandekamer.com/https://www.hetlab.tk/
On Thu, Sep 26, 2024 at 04:29:51PM +0200, Henk van de Kamer wrote:
> Hi,> > > (I just took a while to figure out how to build dusk-curses.> > usermode/README.md. Perhaps the section `Build and run` should come> > before `Packages`? It doesn't seem necessary to understand packages.> > And the sections before and after the build section both mention> > packages, which suggests they may be better off being contiguous..)> > > > (I haven't tried the multilib thing for dusk-sdl yet.)> > It took me two hours to figure out how this is done in Debian 12 (Bookworm).> I created a patch against the README.md in the hope it can be used as> overview how this is done. In the past I used similar examples from other> distros to get things building in Debian.> > May be it would be better to separate the build instructions in a new> document, so detailed instructions for other distros can be added.> > Anyway, I've now done the tour and it is good to see things working, even if> it is still not clear to me why it works :-).> > I'm the author since april 1998 of a three page column called Het Lab -- the> lab -- in a Dutch computermagazine PC-Active. I've learned what people need> to reproduce my work and most of the time that is a lot more of details you> skip over because of how many words fits on a page. I'll probably propose> some articles when I figured out what is my goal: using Collapse OS which is> now hidden somewhere in Dusk OS.> > -- > Henk van de Kamer> https://www.vandekamer.com/> https://www.hetlab.tk/
With so much proximity to the project, it becomes difficult to figure out where
"newcomer showstoppers" are and newcomers, showstopped or not, will seldom
document their experience. So thanks for this, it's needed and welcome.
Regards,
Virgil
Hi Virgil,
On 26-09-2024 16:58, Virgil Dupras wrote:
> With so much proximity to the project, it becomes difficult to figure out where> "newcomer showstoppers" are and newcomers, showstopped or not, will seldom> document their experience. So thanks for this, it's needed and welcome.
I know. And even after 26 years of writing, I still forget things or
think that my audience should know that :-). Your project opens a whole
new world for me, so basically I'm a noob at this point. And as long as
I'm making progress, I won't stop.
For example, your tour -- which prompted me to study the Usermode Dusk
-- has now led me to try it on my A64--OLinuXino from Olimex:
U-Boot SPL 2024.04 (Aug 24 2024 - 16:15:18 +0200)
DRAM: 1024 MiB
Trying to boot from MMC1
.....Dusk OS
92KB used 1009KB free ok
here .x
4a03744c ok
here dump
:4a03744c 3220 5f20 3b20 3a20 726f 7229 2033 205f 2 _ ; : ror) 3 _
:4a03745c 203b 0a5c 2072 6567 6973 7465 7220 7368 ;.\ register sh
:4a03746c 6966 7420 6f70 6572 6174 696f 6e73 2028 ift operations (
:4a03747c 206f 7020 7220 2d2d 206f 7020 290a 3a20 op r -- op ).:
:4a03748c 5f20 2820 6f70 2072 2074 7970 6520 2d2d _ ( op r type --
:4a03749c 206f 7020 2920 6469 7020 3420 6c73 6869 op ) dip 4 lshi
:4a0374ac 6674 207c 203c 3c20 312b 206f 7220 3420 ft | << 1+ or 4
:4a0374bc 6c73 6869 6674 206f 7220 3b0a 3a20 726c lshift or ;.: rl
ok
That is not the clean memory as described. It was clean in the dusk-sdl
binary. Strange? Or is it expected. Let's go on:
here $100 - dump
:4a03734c 0000 8de5 1500 000a 08b0 9de5 0180 a0e3 ................
:4a03735c 0800 9de5 0800 90e0 0800 8de5 0490 2ae5 ..............*.
:4a03736c 0090 dbe5 0490 2ae5 5fae ffeb eba6 ffeb ......*._.......
:4a03737c 0490 2ae5 5e90 a0e3 b3a7 ffeb 0000 a0e3 ..*.^...........
:4a03738c 0000 59e1 0490 9ae4 0200 000a 0490 9ae4 ..Y.............
:4a03739c 0490 2ae5 2e90 a0e3 73ae ffeb e5ff ffea ..*.....s.......
:4a0373ac 0d00 a0e1 0400 90e2 00d0 a0e1 74ae ffeb ............t...
:4a0373bc b2ff ffea 0d00 a0e1 0400 90e2 00d0 a0e1 ................
ok
$cafebabe here !
ok
here @ .x
cafebabe ok
I suspect that with the above, it is has probably overwritten something
it shouldn't:
here dump
:4a03744c beba feca 3b20 3a20 726f 7229 2033 205f ....; : ror) 3 _
:4a03745c 203b 0a5c 2072 6567 6973 7465 7220 7368 ;.\ register sh
:4a03746c 6966 7420 6f70 6572 6174 696f 6e73 2028 ift operations (
:4a03747c 206f 7020 7220 2d2d 206f 7020 290a 3a20 op r -- op ).:
:4a03748c 5f20 2820 6f70 2072 2074 7970 6520 2d2d _ ( op r type --
:4a03749c 206f 7020 2920 6469 7020 3420 6c73 6869 op ) dip 4 lshi
:4a0374ac 6674 207c 203c 3c20 312b 206f 7220 3420 ft | << 1+ or 4
:4a0374bc 6c73 6869 6674 206f 7220 3b0a 3a20 726c lshift or ;.: rl
ok
Yep! Bug? Something I don't understand? Let's keep going anyway:
needs asm/arm
ok
code add42 add) r4 rd) r5 rn) 42 imm) ,)
ok
5 add42 .
The first "command" learnt me something. I still can't wrap my head
around where the files are. Probably in memory? And not in a filesystem
we are used to? Still haven't figured out how the listdir is supposed to
work. But now that I've seen things working, I begin to understand
things better. With breaking working things you learn more then trying
to get something to work which you don't understand. My motto is always
try to have something working before you start experimenting...
The second part I found in your documentation. I didn't find how to
return. ARM assembly is new for me. So I expected that the last part
would hang the machine. Which it did :-). So still learnt something...
--
Henk van de Kamer
https://www.vandekamer.com/https://www.hetlab.tk/
On Thu, Sep 26, 2024 at 05:26:22PM +0200, Henk van de Kamer wrote:
> Hi Virgil,> > On 26-09-2024 16:58, Virgil Dupras wrote:> > With so much proximity to the project, it becomes difficult to figure out where> > "newcomer showstoppers" are and newcomers, showstopped or not, will seldom> > document their experience. So thanks for this, it's needed and welcome.> > I know. And even after 26 years of writing, I still forget things or think> that my audience should know that :-). Your project opens a whole new world> for me, so basically I'm a noob at this point. And as long as I'm making> progress, I won't stop.> > For example, your tour -- which prompted me to study the Usermode Dusk --> has now led me to try it on my A64--OLinuXino from Olimex:> > > U-Boot SPL 2024.04 (Aug 24 2024 - 16:15:18 +0200)> DRAM: 1024 MiB> Trying to boot from MMC1> .....Dusk OS> 92KB used 1009KB free ok> here .x> 4a03744c ok> here dump> :4a03744c 3220 5f20 3b20 3a20 726f 7229 2033 205f 2 _ ; : ror) 3 _> :4a03745c 203b 0a5c 2072 6567 6973 7465 7220 7368 ;.\ register sh> :4a03746c 6966 7420 6f70 6572 6174 696f 6e73 2028 ift operations (> :4a03747c 206f 7020 7220 2d2d 206f 7020 290a 3a20 op r -- op ).:> :4a03748c 5f20 2820 6f70 2072 2074 7970 6520 2d2d _ ( op r type --> :4a03749c 206f 7020 2920 6469 7020 3420 6c73 6869 op ) dip 4 lshi> :4a0374ac 6674 207c 203c 3c20 312b 206f 7220 3420 ft | << 1+ or 4> :4a0374bc 6c73 6869 6674 206f 7220 3b0a 3a20 726c lshift or ;.: rl> ok> > > That is not the clean memory as described. It was clean in the dusk-sdl> binary. Strange? Or is it expected. Let's go on:> > > here $100 - dump> :4a03734c 0000 8de5 1500 000a 08b0 9de5 0180 a0e3 ................> :4a03735c 0800 9de5 0800 90e0 0800 8de5 0490 2ae5 ..............*.> :4a03736c 0090 dbe5 0490 2ae5 5fae ffeb eba6 ffeb ......*._.......> :4a03737c 0490 2ae5 5e90 a0e3 b3a7 ffeb 0000 a0e3 ..*.^...........> :4a03738c 0000 59e1 0490 9ae4 0200 000a 0490 9ae4 ..Y.............> :4a03739c 0490 2ae5 2e90 a0e3 73ae ffeb e5ff ffea ..*.....s.......> :4a0373ac 0d00 a0e1 0400 90e2 00d0 a0e1 74ae ffeb ............t...> :4a0373bc b2ff ffea 0d00 a0e1 0400 90e2 00d0 a0e1 ................> ok> $cafebabe here !> ok> here @ .x> cafebabe ok> > > I suspect that with the above, it is has probably overwritten something it> shouldn't:> > > here dump> :4a03744c beba feca 3b20 3a20 726f 7229 2033 205f ....; : ror) 3 _> :4a03745c 203b 0a5c 2072 6567 6973 7465 7220 7368 ;.\ register sh> :4a03746c 6966 7420 6f70 6572 6174 696f 6e73 2028 ift operations (> :4a03747c 206f 7020 7220 2d2d 206f 7020 290a 3a20 op r -- op ).:> :4a03748c 5f20 2820 6f70 2072 2074 7970 6520 2d2d _ ( op r type --> :4a03749c 206f 7020 2920 6469 7020 3420 6c73 6869 op ) dip 4 lshi> :4a0374ac 6674 207c 203c 3c20 312b 206f 7220 3420 ft | << 1+ or 4> :4a0374bc 6c73 6869 6674 206f 7220 3b0a 3a20 726c lshift or ;.: rl> ok> > > Yep! Bug? Something I don't understand? Let's keep going anyway:> > > needs asm/arm> ok> code add42 add) r4 rd) r5 rn) 42 imm) ,)> ok> 5 add42 .> > > The first "command" learnt me something. I still can't wrap my head around> where the files are. Probably in memory? And not in a filesystem we are used> to? Still haven't figured out how the listdir is supposed to work. But now> that I've seen things working, I begin to understand things better. With> breaking working things you learn more then trying to get something to work> which you don't understand. My motto is always try to have something working> before you start experimenting...> > The second part I found in your documentation. I didn't find how to return.> ARM assembly is new for me. So I expected that the last part would hang the> machine. Which it did :-). So still learnt something...> > -- > Henk van de Kamer> https://www.vandekamer.com/> https://www.hetlab.tk/
The great thing about Dusk is that the answers to your questions aren't too far
away and they're pretty straightforward. Yes, full understanding requires taking
the "full learning" path, but I can give you indicators of where to look, that's
a good learning motivator.
First, the dump. The answer is in the sunxi kernel[1] and u-boot's code[2].
u-boot is designed to boot huge programs, so it reads a lot of sectors (400)
from the SD card to memory. Dusk doesn't waste memory and, because its kernel
and payload is less than $20000 bytes in size, sets its inital HERE there. But
this memory is populated by spurious sectors u-boot has read into it.
So no, you're not breaking anything by writing to it. This is garbage data.
> needs asm/arm> ok> code add42 add) r4 rd) r5 rn) 42 imm) ,)> ok> 5 add42 .
You're using the assembler correctly, but you're using the wrong registers.
You're also not returning[3]. What you're looking for is:
code add42 add) r9 rdn) 42 imm) ,) ret,
5 add42 .
47 ok
Informations about registers are in doc/hw/arm[4]. "rTOP" is an alias for "r9".
ARM is a bit weird and doc/asm/arm doesn't make much sense until you read about
ARM first. But I think that once you do, the docs become adequate. Let me know
if they turn out not to be.
Files are in a FAT on the SD card. You should be able to mount the SD card
you've created for the OLinuXino as FAT and browse the files. The kernel and
payload are in the "Reserved Sectors" part of the FAT.
This happens in the Makefile[5].
I hope this helps!
Regards,
Virgil
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/xcomp/arm/sunxi/kernel.fs#L17
[2]: https://github.com/u-boot/u-boot/blob/v2024.04/common/spl/spl.c#L257
[3]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/asm/arm.txt#L209
[4]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/hw/arm.txt
[5]: https://git.sr.ht/~vdupras/duskos-deployments/tree/master/item/a64-olinuxino/Makefile#L19
On 26-09-2024 18:01, Virgil Dupras wrote:
> The great thing about Dusk is that the answers to your questions aren't too far> away and they're pretty straightforward. Yes, full understanding requires taking> the "full learning" path, but I can give you indicators of where to look, that's> a good learning motivator.
Thanks! I already learnt some new things, which is always nice.
> First, the dump. The answer is in the sunxi kernel[1] and u-boot's code[2].> > u-boot is designed to boot huge programs, so it reads a lot of sectors (400)> from the SD card to memory. Dusk doesn't waste memory and, because its kernel> and payload is less than $20000 bytes in size, sets its inital HERE there. But> this memory is populated by spurious sectors u-boot has read into it.> > So no, you're not breaking anything by writing to it. This is garbage data.
I've a Banana Pi which I use as an internal IMAP server an lately as an
webserver as well. For that I needed to compile my own full U-Boot and
created scripts to start the Linux kernel, initial ramdisk and dtb. I
even created a part where it looks at an GPIO pin, so we could start the
last working kernel.
I knew that a small part was the SPL, but other then the message, you
don't see that. So using it this way was interesting. In the Sunxi docs
I even found why you copied with 8 kilobyte of zeroes before it. That is
where the BROM looks for a valid signature. Which leaves the first 8
kilobyte clean to add an MBR and newer GPT if needed.
>> needs asm/arm>> ok>> code add42 add) r4 rd) r5 rn) 42 imm) ,)>> ok>> 5 add42 .> > You're using the assembler correctly, but you're using the wrong registers.> You're also not returning[3]. What you're looking for is:> > code add42 add) r9 rdn) 42 imm) ,) ret,> 5 add42 .> 47 ok> > Informations about registers are in doc/hw/arm[4]. "rTOP" is an alias for "r9".> > ARM is a bit weird and doc/asm/arm doesn't make much sense until you read about> ARM first. But I think that once you do, the docs become adequate. Let me know> if they turn out not to be.
Will do. And thanks for the example!
> Files are in a FAT on the SD card. You should be able to mount the SD card> you've created for the OLinuXino as FAT and browse the files. The kernel and> payload are in the "Reserved Sectors" part of the FAT.> > This happens in the Makefile[5].
Mounting it, was already on my list of experiments.
Thanks for all the links, means I've a lot of reading to do :-).
--
Henk van de Kamer
https://www.vandekamer.com/https://www.hetlab.tk/
Hello,
Am 26.09.2024 um 17:26 schrieb Henk van de Kamer:
> The first "command" learnt me something. I still can't wrap my head> around where the files are. Probably in memory? And not in a filesystem> we are used to? Still haven't figured out how the listdir is supposed to> work.
you can do
f<< home/sh.fs
ls /doc
and it will return a file listing.
ll /tests
also works, so does
edit /home/sh.fs
(puts you into ged)
Unfortunately, at least in v11,
ls /
is broken, so you cannot find out what is in your root directory (at
least not this way). So you have to remember it from when you last
mounted the directory, or write it down, or print it if you have a
working printer :)
Regards,
Michael
PS: Yes I am notorious in forgetting file names, sometimes I forget the
name just after I named and saved a new file, so I look at the most
recent files to see how I named it. Probably if all I had was Dusk, I
would get better in remembering, or write it down on a piece of paper.
On Thu, Sep 26, 2024 at 07:10:08PM +0200, Michael Schierl wrote:
> Unfortunately, at least in v11,> > ls /> > is broken, so you cannot find out what is in your root directory (at> least not this way). So you have to remember it from when you last> mounted the directory, or write it down, or print it if you have a> working printer :)
To list the root directory, it's "listdir" with dirid 0:
0 bootfs listdir
But otherwise yeah, I should do something about "ls /".
Hi Virgil,
> The great thing about Dusk is that the answers to your questions aren't too far> away and they're pretty straightforward. Yes, full understanding requires taking> the "full learning" path, but I can give you indicators of where to look, that's> a good learning motivator.
Thanks for the indicators. Really appreciated!
> First, the dump. The answer is in the sunxi kernel[1] and u-boot's code[2].> > u-boot is designed to boot huge programs, so it reads a lot of sectors (400)> from the SD card to memory. Dusk doesn't waste memory and, because its kernel> and payload is less than $20000 bytes in size, sets its inital HERE there. But> this memory is populated by spurious sectors u-boot has read into it.> > So no, you're not breaking anything by writing to it. This is garbage data.>
After two hours I didn't succeed to find the garbage in the 200 plus 40
-- 8 + 32 for MBR plus SPL -- kilobyte. I did find in the U-Boot source
code why it starts with 0x4a000000. Then my eye caught the if part:
#if CONFIG_SYS_MONITOR_LEN != 0
spl_image->size = CONFIG_SYS_MONITOR_LEN;
#else
/* Unknown U-Boot size, let's assume it will not be more than
200 KB */
spl_image->size = 200 * 1024;
#endif
Looking in the u-boot.cfg which it used to build the SPL I found:
#define CONFIG_SYS_MONITOR_LEN 786432
So it reads even more :-). And with that I found the " ror) 3" string as
follows:
hvdkamer@ontwikkel2:~/duskos/duskos-deployments/a64-olinuxino$ hexdump
-C dusk.img | grep -E ' ror) 3'
00041450 3b 20 3a 20 72 6f 72 29 20 33 20 5f 20 3b 0a 5c |; : ror) 3
_ ;.\|
In memory the above data starts at 0x4a037450. So I'm not there yet, but
with the above I no know it is indeed garbage. And that there is more of
it :-). Not clear why there is a 16 kilobyte difference. But at least I
begin to see how it works.
--
Henk van de Kamer
https://www.vandekamer.com/https://www.hetlab.tk/