Відео

🔥🤘🤘🔥

Thanks

Yeah, and a lot of it is probably buggy!

@@QuesoFuego I'm sure you'll sort it out. :D

It is a bit scattered around and not well explained. But it's really just an interface or api definitions for a library/framework, that gets info for various devices or parts of firmware. The implementation of that library is hidden, it's implemented in firmware, but you have documentation for how to talk to it, essentially.

I'm 29, and it's been about 6-7 years of off and on learning and hobby programming, and having a job using a C-like language (RPG). I wouldn't say I have skills, I'm pretty slow with things and it's hard to program on camera and talk and think at the same time, but I do read a lot and try to get several different perspectives or articles on doing any one thing, to be able to understand it. Also making and testing a few different versions before making a video on something. Lately that includes studying documentation or original sources where available, which can take a awhile to piece together a program or project. I'm also pretty stubborn and will keep trying just about every permutation and combination of things until it works, then will remove things until it doesn't work, and try to find a balance between those two. Then think about why it works in that configuration, and if it can be improved further with your new knowledge and understanding, and why, and repeat. I'd say perseverance and time has helped way more than any knowledge or talent, for what it's worth.

That works! It would be simpler, I was curious about reading disk blocks and didn't want to be limited to only the EFI system partition.

You could write the OS.bin file directly to a usb with dd or rufus, but it probably won't work in protected mode unless usb somehow emulates an ide drive. ATA PIO would not work, it needs a proper USB stack, and ehci or xhci support, which is a lot of work. I use a SATA to USB cable to write to an ssd and boot from that, which is less convenient, but works for now.

@@QuesoFuego thanks you very much

Oh wait nvm i forgot that DIR_Name has spaces and not null bytes at the end

There are 2 ways I can think of solving this, 1. memcpy from start to another char array with length of 11. Then compare that. 2. Make a function in assembly using the rep instruction, with rcx set to 11-strlen(start) and eax to 0x20(space char) Then check if rcx reaches 0, if it does then it is the same, else there is something else after the initial string. The code would be char *aft_name = DIR_Name +strlen(start); int length = 11-strlen(start); asm(“ mov $0x20, %%al mov %[name], %%rdi mov %[len], %%ecx rep scasb mov %%ecx, %[len1]”:(len1)”=m”(length):(name)”m”(aft_name), (len)”m”(length):”rdi”,”ecx”); If(length == 0) printf(“it is equal”);

I'd probably want to prevent files being added with non-8.3 compliant names when getting the command line flags, or convert file names to 8.3 at that time. That would ensure any file names are 11 length or less and prevent other issues.

Yes, it only refreshes the rows/cols from QueryMode(), which is in the main loop. It would stay in the same spot until getting the new row/col values there. Probably would want the context globally or passed around, and update it immediately when needed such as changing the text mode, or using CloseEvent() for the timer event to stop it, and adding back the timer event later.

Yeah mine too... 😅 Keep finding stuff to add.

Thank you! Appreciate it!

It should be 12 yes, to handle the null byte. Otherwise can get the length in digits and make a length specifier for printf, .*s or $1 or similar. I expanded the buffers later on to char[24], int64_t is around 21 or 22 with the sign character and a null byte.

Yes, some time. Probably an NES or gameboy, or a different 6502 or z80 based machine like C64 or zx spectrum, something like that.

@@QuesoFuego That's cool ! Since you're still hesitating on what machine to emulate, I'd suggest the 8080 space invaders arcade machine, as it is somewhere between the chip8 and the gameboy in terms of complexity. But whatever you choose, I'll watch it.

@@QuesoFuego A ZX Spectrum would be cool because the graphics are simple. I always find the tutorials about the Gameboy and NES to be overwhelming, and I'm sure that's the case for most people. The ZX Spectrum is a nice step after the Chip-8 without being overwhelming.

The only video tutorial about space invaders is this one : ua-cam.com/video/Oyz4yRvYK0s/v-deo.html c#, visual studio, using form and all...eww.. The way QuesoFuego is doing it (c/sdl) would be much more instructive.

Learning C would be best done by programming in C, and making projects you are interested in and looking things up when you get stuck or want to know better/different ways of doing something. I can't tell you how to learn, only that it takes a lot of time and effort, and only you can know how you learn things. There isn't a single place or thing for learning programming with no experience, usually school does that or you find some random thing or website and try out html and js, or python, or scratch, or C, or assembly, or anything else, and want to do something with it like make games, cheats, graphics programs, drivers, reverse engineering, making an OS, etc. You search up on the topics that interest you and how to do them, starting could be as simple as writing a text file and compiling it and running the program, or making an index.html page and loading that in the browser, and then you go from there. You'd want to learn a given language's syntax and semantics, control flow, data flow, data structures and algorithms, built-ins, libraries, etc. but you only learn these things by writing the language and making things and running them, and debugging and all the other fun stuff that comes with it. Maybe the most recommended nowadays for C books is: C Programming: A Modern Approach, 2nd Edition by K. N. King But also the classic C book: C Programming Language, 2nd Edition by Brian W. Kernighan and Dennis M. Ritchie You could use gcc with -std=c89 for that book, but some aspects may not work the same today as they did decades ago. For low level in general, ideally you'd know computer organization and architecture, different hardware protocols and communication standards, up through assembly language and the ISA for your given processor, file formats, object and executable formats e.g. ELF vs PE files, and how your OS operates on top of all that and how to interact with it, via syscalls or including system headers, and other means. That would make C and any other higher level languages make more intuitive sense, as to what they can translate into and run as (the actual operations that happen are different on the cpu, but that's getting into hardware that you can't change, more so than software that you can change). A couple books for bottom up learning or more low level topics would be: Code: The Hidden Language of Computer Hardware and Software by Charles Petzold The Elements of Computing Systems, second edition: Building a Modern Computer from First Principles by Noam Nisan, Shimon Computer Systems: A Programmer's Perspective by Randal Bryant, David And also maybe some patterson and hennessy books on computer architecture or organization for a given ISA (x86, arm, risc-v, etc.) A couple assembly language books, as extra. These are for x86, but arm & others probably have similar things out there, and their own assemblers like cc65 for 6502 for e.g. nes programming, things like that: x64 Assembly Language Step-by-Step: Programming with Linux (Tech Today) 4th Edition by Jeff Duntemann Modern X86 Assembly Language Programming: Covers X86 64-bit, AVX, AVX2, and AVX-512 3rd ed. Edition by Daniel Kusswurm

Thank you so much, I really appreciate this. I will get started on buying the book for c and start my way from their!@@QuesoFuego

Thanks! Will look into doing these. I was trying to do asteroids but with floating point instructions for accurate turning and acceleration it was ending up a lot larger than 1 sector. May still do that anyway and just load additional sectors. Frogger or tapper I think would be easiest out of those, although original lemmings probably doesn't have that complicated logic for path finding/collision. Different jobs and selecting parts of the level would be interesting to implement. Paperboy I'd want to have some sort of scrolling, maybe a generated level or large map, which might overflow a sector by a bit. Appreciate these suggestions!

@@QuesoFuego thanks for the video.. Architecture-wize I'd opt for an UEFI engine, to provide the first step of drawing (screen, border, colors, fill, etc). You'll only need to unify data structures accordingly. Syntax-wize I could also share some pointers, but I recon this topic nowadays only renders discussion.

Wow, it's in the thumbnail as well, I really didn't read those 2 sentences until now. Been relying on my laptop behaving correctly for these. Well, I can do this at the start of the next one then. Can have a retry count and loop on ExitBootServices(), if it errors on invalid parameter then will call FreePool() on the mmap buffer, call get_memory_map(), and ExitBootServices() again. Fails after say 3 tries then will count that as the hard error.

​@@QuesoFuego you can allocate a larger buffer the first time and if the call to ExitBootServices fail you can reuse it 🤷‍♂️ GetMemoryMap should always be called with a buffer larger than it needs to avoid problems.

Yeah not sure why no one proof reads it first

You may need a bochs-sdl package if that exists, or you can try "display_library: x" for x11.

@@QuesoFuego thank you it works perfectly with the display library x

I'm a Programmer/Analyst in a transportation company, they do trucking and general freight handling/shipping, warehousing, logistics, etc. I mainly handle backend and (some) full stack applications for an IBM i system (AS/400). Mostly business logic and reports, some database programming and querying, web services, API integrations, scripting, or whatever else they ask for. My primary languages for work are RPG and SQL, maybe kotlin and JS/TS in a few years if we switch over more to mobile devices and cloud apis. Not really open to LinkedIn or IRL connections right now, but might be in the future.

Thumbnail isn't great, very niche topic, lack of SEO, UA-cam algorithm changes all the time, etc. etc.

Awesome, glad to hear it!

Killing enemies gets thin blood which gives the vials, if you mean the charge shots I think that's from story progression for specific characters. Mask de smith gets 3 charges and later 5 when he gets new outfits

ConIn ReadKeyStroke() gets one key at a time, you could loop on that and add to a buffer until you get an ' ' for the enter key, and return then or send the buffer somewhere. That'd be closer to a line buffered stdin.

Thanks! Appreciate it

Sir, this is a moai house 🗿

Waiting for some Indian to make some hate comments (I am not Pakistani)

Yes, you can load additional disk sectors with bios interrupts, int 13h ah=02 en.m.wikipedia.org/wiki/INT_13H You could load data after the boot sector with that, or anywhere on the disk that it's written to, as long as you know the starting sector number. If it's low or right after the bootsector, then you could use cylinder 0 and head 0, but sector is 1-based, 1-63. ES:BX would point to the memory address to load into.

Error handling would probably be more streamlined with option types, and structs could have #[repr(C)] or #[repr(packed(1))]. Functions maybe as well, but those may not be needed to have C representations. There's at least 1 UEFI crate for rust I found github.com/rust-osdev/uefi-rs there may be others, I'd have to research how it does things as a wrapper for uefi ------------------------------------------------ O tratamento de erros seria provavelmente mais simplificado com tipos de opção, e os structs poderiam ter #[repr(C)] ou #[repr(packed(1))]. Funções talvez também, mas elas podem não ser necessárias para ter representações em C. Há pelo menos 1 UEFI crate para rust que eu encontrei github.com/rust-osdev/uefi-rs pode haver outros, eu teria que pesquisar como ele faz as coisas como um wrapper para uefi

Awesome, thank you

According to this en.wikipedia.org/wiki/Programmed_input%E2%80%93output PIO mode 4 is up to 16.7MB/s and mode 5 is for compact flash and up to 20MB/s, the device itself should report speeds in some parts of the IDENTIFY command output from 0xEC or 0xA1, but DMA/UDMA would usually be faster than any PIO.

I've looked into the link, and could find only mention about different signal DIOR/DIOW/IORDY timings. I think it makes sense only for PCI IDE adapters, for ISA 8MHz bus clock is the limit. So polling code will be the same for all PIO modes? So what is really the difference for programmer? @@QuesoFuego

Polling would the the same, yes. The speed and transfer rate would be different, but that's about it

Thank you@@QuesoFuego

Thanks, I will work on making them easier to follow for the future