pulkomandy

pulkomandy, 3 months ago

No one knows about it? :(
Today I read the book "A little Smalltalk" which explains how it is implemented. It looks simple enough for me. The book describes version 1. Version 3 is supposedly less tied to unix, but it adds some windowing support for mac os and so on. Version 4 has a garbage collector instead of reference counting, is that better? I don't know. I guess next I have to compile them on some unix system and see holw large the binaries and smalltalk images are.

pulkomandy, 3 months ago

The idea is quite interesting: there is a REPL where you can create objects and call methods. But, unlike in "big" smalltalk, there is no gui and you can't directly write new classes from the repl. Instead you write classes in an editor, and then run them through a compiler that converts them into bytecode. The interpreter then has commands to import that bytecode and add it to the class list (in v3 this is done method by method instead of by whole class)

pulkomandy, 3 months ago

So, it would be a lot of file operations if done exactly this way with a typical 8bit microcomputer. You get the worse of compilers (messing with text editors, running multiple commands) and of interpreters (it is slow). Is the generated code small enough that it would be worth it? Could one build a "frozen" set of classes and cross-compile them, and get a workable repl with lots of features running on the target system?

pulkomandy, 3 months ago

I tried compiling them (on Haiku for now). Surprisingly, version 4 is the smallest despite having more features. Code size is only 0x3000 bytes! But there is quite a lot of bss (ram usage), 0x4c00 bytes, and there is the smalltalk "image" which is over 100K. But I could probably remove some things from there (who need fractions?) and I think it will be smaller on an architecture using 16 bit pointer and integers?

pulkomandy, 3 months ago

Unfortunately I think version 4 relies too much on a 32bit system, the older versions are more likely to work in a 8/16bit system I think. But can they be made smaller as well?

pulkomandy, 3 months ago

Well, after closer study of the code, I think the comments in version 4 refer to 32bit systems, but the code is more generic than that. I hacked it a bit (removed all file io operations, that makes it completely useless for now since that includes loading the "image" with smallealk bytecode to run).
this results in a 24K binary. Not bad, I guess? That's unoptimized sdcc, so, hand optimized assembler would do a lot better. And I have kept 64bit int and some float support using sdcc floats

pulkomandy, 3 months ago

I think the 64bit ints can be replaced with 32bit ones, and the sdcc floats by cpc firmware ones (which are not better, but they are already in the cpc rom so that would be less code to include).

However, I did not manage to execute anything on cpc yet. It either reboots the chc, or returns to basic immediately. I probably did something wrong converting the ihx file to cpc binary... Ran out of time today, will try again later...

pulkomandy, 3 months ago

Ok, after setting up a correct crt0.s, it is trying to do something. The first step is trying to allocate 3 times 40k of ram for the heap and garbage collector, that's not going to work! Let's reduce this hardcoded size to something smaller. But still I'm not sure the two-space garbage collector is the best choice here...

pulkomandy, 3 months ago

The malloc provided by sdcc only allows allocating up to 1024 bytes (not per allocation, that's the total size of the heap). Well, that's not going to work...

pulkomandy, 3 months ago

Well I added the missing code, and now I get a black screen instead of a desktop. Not the first time I get into that kind of situation with this driver, where fixing bugs makes things worse :(

pulkomandy, 3 months ago

External DVI display working, now let's see about getting the internal one back as well...

pulkomandy, 3 months ago

Ok, sometime this week I got the internal display sort of working (probably only on my machine). I still can't get both displays working at the same time, so, some initialization is missing still. I wanted to dump all videocard registers and compare the dumps with either screen on, but the function to dumh registers freezes the machine :( so I have to understand why that is...
Also unrelated to this: I finished preparing our code for ffmpeg6, so that's one thing off the todolist!

#HaikuOS

pulkomandy, 3 months ago

I suspect the register dumping code accidentally triggers some "clear on read" behavior on some register, but I can't find which one. I looked at the register dump tool for Linux but it doesn't seem to do anything special. I guess the Linux driver "locks" some register ranges by writing some magic values to "key" registers, but our driver leaves them unlocked? But still, I have to find which registers that is. My strategy now is to dump smaller ranges until I find the problematic area

pulkomandy, 3 months ago

But the compile-install-reboot-test cycle for this isn't really fun. I'm not sure how I could make this faster. Maybe by adding a driver settings file where I can configure the dump size. Right now I have the register dump code wired to the "wait for retrace" call, since that's not used by the desktop, I can trigger it by starting glteapot. But that's not a great way to add debug commands :)

pulkomandy, 3 months ago

I considered a kernel debugger command (the driver already has some), but this dump is more easily done in userspace in the accelerant.

pulkomandy, 3 months ago

I am narrowing down the address range where there's a register that crashes the system by just reading it. I got it down to 32KiB today, I'll continue tomorrow.
If you have an idea which register in intel graphics (gen 11) in the range 60000-64000 may cause that, I appreciate your help!
But I think all other people who might know about this all work at Intel?

#Intel #graphicscard

pulkomandy, 3 months ago

This board is made from documented chips, there's a video converter driven by a 8051 based tv controller, whicq I think does OSDfor the configuration menu. The gbs-control project disables that controller and uses an esp2866 arduino thing instead to program the video converter.
I run my own custom thing (on an old TI launchpad board) because I use it as a simple "line doubling" converter, providing a high quality (no scaling) and low latency output

pulkomandy, 3 months ago

It would be great if Icould do this on the 8051 that's on board instead of having a devboard permanently attached to it.
But also, if Icould get the OSD to work, I can in theory use this as a standalone computer, maype run Contiki on it or something like that?
Unfortunately, this has been on my todo list for 10 years or so. First of all Ineed to write a tool to read and hrogram that 8051 chi, (if I remember correctly it is done over i2c)

pulkomandy, 3 months ago

@santiago @libreleah I don't think Haiku works well with libreboot, at least it di.n't last time someone tried, and the bugreport is still open (on Haiku side)

pulkomandy, 3 months ago

So, it turns out BMenu::SortItems was broken ince its introduction in Haiku back in 2021, and the only place using it (in Haiku sources, di.n't check 3rd party apps) had a workaround for the bug. That's what I get for trying to use fancy new and still undocumented APIs! (I also wrote the API docs, now that it works...)