OSDev.org

Looking very good, nice job .

"NEVER write big IRQ handlers and collect IRQs from a device!!! That?s not possible! [...]
The Probblem is that the PIC can?t store IRQs from the same device. If the IRQ handler still working and a new IRQ(from the same device) is activated then you got a problem " - Osbios from osdev.org

New iso image didn't works too....

Have started cdrom.686.iso in vmware 4.5.1.

works perfectly. Have started two instances of mpeg2decode. This causes the playback to lag a bit but that's not important I reckon

Here's a screenie:



Important: you have to start spoon from cdrom IDE primary slave (device 0:1) in order to get it running correctly.

beneath thats the shell causing a pagefault after me issueing the command "ls" five or six times. (it's scrolling up the second time - first time scrolling does no harm)




stay safe

Yes, if i run spoon from the primary slave cdrom it works, but when i play trailer, there was a real exception (invalid opcode)

It works, when i run it that:
mpeg2decode -b /spoon/system/media/1.mpg -o6
I must ported this program on the my system ;D

Excellent. This is progress I'm feeling better. .

Sandman/intel_breaker.. I definitely think it's the CPU then It's attempting to use some newer features which I'm not checking for and, it's causing an invalid opcode. I don't recall ever checking for AMD specific support. This is my downfall. The Athlon ISO is built specifically for all those enhanced AMD features and the mpeg2decode app will make use of those because it's doing a lot of math.

Beyond infinity, thanks IDE 0:1 and I didn't even realise! I'll revise the ATAPI detection code as well. It is also a little suspicious.

Umm.. that shell thing is a bug in my command line history handling. I'm doing something wrong, but I'll fix it. It's just a simple coding problem and not anything critical. (in the sense that it requires major work).

Excellent again! -f -r are math related options. Tada. That further supports the AMD math thing.

It's easy to port I link it against my C99 almost-compatible libc and I just provided a little hook into a GUI Window. It's actually very easy.

I tested spoon under bochs and when running the gui i can't move the mouse but the clock looks to work.

I get these bochs warnings when cdrom booting is used:



[tt]
# configuration file generated by Bochs
config_interface: textconfig
display_library: win32
megs: 128
romimage: file="BIOS-bochs-latest", address=0xf0000
vgaromimage: file="VGABIOS-lgpl-latest"
boot: cdrom
floppya: 1_44="a:", status=inserted
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
ata0-slave: type=cdrom, path="spoon.iso", status=inserted, biosdetect=auto, model="Spoon CDROM"
ata1: enabled=0
ata2: enabled=0
ata3: enabled=0
parport1: enabled=0, file="parport.out"
parport2: enabled=0
com1: enabled=0, mode=null, dev=""
com2: enabled=0
com3: enabled=0
com4: enabled=0
i440fxsupport: enabled=0
usb1: enabled=0, ioaddr=0xff80, port1=, port2=
sb16: enabled=0
floppy_bootsig_check: disabled=0
vga_update_interval: 300000
vga: extension=vbe
keyboard_serial_delay: 250
keyboard_paste_delay: 100000
floppy_command_delay: 500
ips: 2500000
text_snapshot_check: 0
mouse: enabled=0
private_colormap: enabled=0
clock: sync=none, time0=local
ne2k: enabled=0
pnic: enabled=0
# no loader
log: bochsout.txt
logprefix: %t%e%d
debugger_log: -
panic: action=ask
error: action=report
info: action=report
debug: action=ignore
pass: action=fatal
keyboard_mapping: enabled=0, map=
keyboard_type: mf
user_shortcut: keys=none
# no cmosimage
gdbstub: enabled=0, port=8383, text_base=0, data_base=0, bss_base=0
[/tt]

hi.

Thanks for testing I don't use Bochs, so I don't know too much about it but I did a quick search. Forgive me if I'm wrong, but:



Are you sure the mouse is enabled? Logically, I would think that this should be "enabled=1". I did a search on the net and I found different configs, some with 0 and some with 1.

Durand.

I just tested with mouse: enabled=1 it just enables the mouse at start. Its the same as pressing the mouse icon in bochs.
But the test had the same result, mouse didn't work.
But i think its more a problem with bochs :s it isn't the first os i tested on it that didn't have a working mouse input.

Yeah :/ Precisely the reason I don't test with a emulator or virtualizer. They have their quirks which mess you around and you could spend hours debugging something which doesn't make sense and it turns out that it's just Bochs/Qemu/VMWare.

Or.. you could develop for weeks using Bochs/Qemu/VMWare and the first boot on real hardware will fail. Why? They could be doing something extremely silly.

VMWare versions less than 4 never used to handle CR3 correctly during task switches. Tsk.

Bochs, Qemu don't support features out of the box - so I regard them as unsupported. Why must it be so difficult for people to test? (Recompile bochs with --with-feature1 --with-feature2. Use the VBE bios file xxxx.bin with Qemu).

The easy solution: burn to CD, boot on a real computer. No mess. No fuss. Just a reboot and 1 CDWR required. Gauranteed to have 100% hardware behaviour.

If something doesn't work, I'm 99% gauranteed that it's my fault.

hi, all:
I ported this program on the my OS.
it's the screenshot:

Awesome! it's a cool little application that's mostly written very nicely.. so it's portable. Did you have a lot of trouble?

it's based on spoon version's code. I just modified spoon.cpp . durand, thanks for your work!