I might have gone overboard detailing the 3D asset(s). 

Scaling down to ~800 triangles shouldn't be too difficult. The mesh has not been optimized for the target hardware/engine yet anyways.

I guess the next step is to rig the mesh, but I wonder how animations will work. There's not enough processing power for full-blown bone weighting, there's not enough memory for vertex animation and slicing up the mesh into individual objects for each bone is just plain ugly.

I could also try to texture the mesh, but I have never done that before and knowing me it will take a truly ridiculous amount of time, so I'd rather not.

FINALLY. DONE. (well, close enough)

[spoiler]
565 vertices, 687 faces, 1,113 triangles.



Crappy background image reference not included.
[/spoiler]

Quote from: xlibman on June 07, 2017, 04:04:15 PM
You normally do your 3D models on paper with a pencil?

I'm not that insane, but I do model with hand-drawn reference sketches as background images.

I normally just doodle when bored at school or when slightly drunk in a bar. I usually don't do 3D models because I don't have access to my workstation in both situations and because it takes me forever to model anything.

I'm still working on the model. It's mostly done (only the hands are missing), I'll make a post when it's finished. I'm currently at 547 vertices, 655 faces and 1,063 triangles, but there's plenty of room for dumbing down the mesh.

Oh my God, I forgot how time-consuming this is...

[spoiler]
340 vertices, 424 faces, 686 triangles total. Obviously still a WIP (soooo many things to touch up), can be simplified later if needed.



I drew a character sheet reference to model from, but I'm not too satisfied with it so I don't think I'll upload it.
[/spoiler]

Next time I'll stick to pencil and paper

I'll have to make some drawings first before attempting to model anything. I'll try to do that as soon as possible.

According to the posts I've seen, it looks like gLib can output roughly between 2500 and 5000 triangles per second, about an order of magnitude less than a typical PlayStation 1 game. A Star Fox clone running at ~20 FPS sounds doable, especially with tricks like LOD or precalculated culling. The original Crash Bandicoot trilogy could push a truly ridiculous amount of polygons per seconds with these tricks, but you'd run out of RAM pretty quickly with that approach here.

Probably, though I would rather compare with in-game Resident Evil 3. I do need to dust off Blender, I don't have any models to show (and before that, I need to draw character sheet references to model from).

Hmm... Given the target hardware's limitations, I take it you're expecting high-end in-game, PlayStation 1-grade models and textures?

It's been a while since I've played with Blender, but last time I did manage to create and rig basic, untextured humanoid models. I also happen to draw and I'm bored of fulfilling requests from rather single-minded fellow students.

Care to give me a description of what you're looking for? Even if my humble modelling and untried texturing skills end up not being up to the task, I could use some new ideas for doodling.

You want to declare an opaque pointer, like how FILE is declared in stdio.h :

typedef struct _IO_FILE FILE;

Then you'd define struct _IO_FILE somewhere else :


struct _IO_FILE {
  int _flags;           /* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags

  /* The following pointers correspond to the C++ streambuf protocol. */
  /* Note:  Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
  char* _IO_read_ptr;   /* Current read pointer */
  char* _IO_read_end;   /* End of get area. */
  char* _IO_read_base;  /* Start of putback+get area. */
[...]
};


More details at http://stackoverflow.com/questions/5299261/c-typedefed-opaque-pointer.

I got U-Boot booting. It is held together with a lot of duct tape, but it works.

I put it over at https://github.com/boricj/u-boot.


initcall: 31fa9a70


U-Boot 2016.03-00320-ga119357-dirty (Mar 24 2016 - 19:29:07 +0100)

initcall: 31f9a8dc
U-Boot code: 31F93000 -> 31FB9AF0  BSS: -> 31FEF5FC
initcall: 31f93370
CPUID: 32450003
FCLK:    0.531 MHz
HCLK:    0.531 MHz
PCLK:    0.265 MHz
initcall: 31f9a90c
DRAM:  initcall: 31f93f4c
initcall: 31f9ab30
Monitor len: 0005C5FC
Ram size: 00000000
Ram top: 32000000
initcall: 31f9a6fc
[...]
initcall: 31f9ab08
initcall: 31f9aa60

RAM Configuration:
Bank #0: 30000000 32 MiB

DRAM:  32 MiB
initcall: 31f9a744
New Stack Pointer is: 31b92ee0
initcall: 31f9a9d4
initcall: 31f9a964
Relocation Offset is: 00000000
Relocating to 31f93000, new gd at 31b92f08, sp at 31b92ee0
initcall: 31f9abfc
initcall: 31f9ac04
initcall: 31f9ad50 (relocated to 31f9ad50)
WARNING: Caches not enabled
initcall: 31f9ac1c (relocated to 31f9ac1c)
[...]
initcall: 31f9ac84 (relocated to 31f9ac84)
initcall: 31f9ac68 (relocated to 31f9ac68)
Net:   No ethernet found.
initcall: 31f9ac5c (relocated to 31f9ac5c)
### main_loop entered: bootdelay=5

### main_loop: bootcmd="<UNDEFINED>"
hp_prime # help   
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
[...]
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
version - print monitor, compiler and linker version
hp_prime #  version

U-Boot 2016.03-00320-ga119357-dirty (Mar 24 2016 - 19:29:07 +0100)
arm-none-eabi-gcc (4.8.4-1+11-1) 4.8.4 20141219 (release)
GNU ld (2.25-5+5+b1) 2.25
hp_prime #


Quote from: DJ Omnimaga on March 16, 2016, 02:07:26 AM
If by bare-metal you mean modifying the hardware or connecting stuff to it in order to hack it, then I'm afraid that the audience might be smaller.

I guess I'm the only guy in the whole world (outside of HP) that has soldered a few wires to his HP Prime's motherboard in order to access the UART.

By bare metal I mean programming directly against the hardware, without an operating system (Rip'Em doesn't use the original firmware at all).

Quote from: Lionel Debroux on March 16, 2016, 06:45:12 AM
By now, I'd basically answer no, unfortunately. Much to the dismay of Tim Wessman, Cyrille de Brébisson and other HP folks, despite its raw power and the fact that it's an open platform, the Prime hardly received such work in the past two years and a half since it became available...

If the fate of third-party firmware and native development on the HP Prime rests on my shoulders, then we're all screwed 

Quote from: DJ Omnimaga on March 15, 2016, 11:40:59 PM
What issues are you having right now?

Accessing the NAND isn't something straightforward to do. The protocol to access it has to be essentially bit-banged raw through the NAND controller and any write would require dealing with ECC.

But I'm thinking about the big picture here. The HP Prime has enough punch to make bare metal development a questionable choice. Since NetBSD and U-Boot have ports running on hardware close enough to the HP Prime, I might as well port them instead of writing my own knock-off drivers, C standard library, interrupt handlers and so on.

So the question is : is anybody interested by bare metal development on the HP Prime ? If no then I should stop wasting time making a decent SDK ; I should instead use what I already have right now to chainload U-Boot and NetBSD.

I 'm banging my head against the NAND. I guess being able to read the 2048 first bytes of the NAND counts as progress compared to no NAND support

I'm starting to wonder if porting U-Boot+NetBSD would be a better idea than writing an entire SDK+Bootloader on bare metal...

I dumped the raw old-school disassembly notes of the first few KiB at https://tiplanet.org/hpwiki/index.php?title=BXCBOOT0.BIN_reverse_engineering. I should be able to (ab)use the subroutines in there for reading the NAND.

I don't intend to reverse engineering all of BXCBOOT0.BIN (not especially all by myself), but if I could locate a subroutine that writes to the NAND it'd be nice to have.

Quote from: Vogtinator on March 08, 2016, 03:38:33 PM
IDA 5.0 is free and a huge step up compared to objdump -D...

If I remember well, IDA 5.0 only supports x86 disassembly and it doesn't run under Linux.