OMG! ZIRIA! ZIRIA!!! IT ACTUALLY HAPPENED!! 34 YEARS LATER!! The epic/legendary Tengai Makyou/Far East of Eden: Ziria JRPG has finally been localized! Supper the Subtitler struck again! Simply unstoppable, NOTHING can prevent him from TOTAL PCECD localization domination!!!! WHACHA GONNA DO BROTHER?!?!
Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - MooZ

#1
Tim Follin ZX Spectrum 1 bit tunes are awesome.

By the way any news on a possible release before Christmas ? :)
#2
It's still sort of active. You are more than welcome if you want to translate the script :)
#3
Well I'm not in a hurry. I don't think I'll have enough new material to release something at datastorm this september anyway.
#4
Maybe you can postpone the multi song stuff for a v2 :)
#5
Damn I'd definitively need this.
I'm tired of 200KB vgm :/
#6
Arkhan: It's just a standard VGM player. All the merits go to Octapus.
#7
Hey people, I should post here more often...

 Some weeks ago I released an intro (read a small rushed demo) at the kickass Datastorm party.
This prod was a good exercise on self modifying code and sprites.
Here's the link on pouet.net.

Months earlier I also released an invit for that party (pouet link).
http://www.youtube.com/watch?V=O1LLmgFLWIE - Invalid ID


This may not be technologically ass whooping. Anyway I hope you'll enjoy it.
#8
Cool to have a new demogroup on PCE!
I'm currently super busy with a small prod for the next datastorm. Hopefully it will be over next week :)
Anyway, I'll be more than happy to lend a hand.
#9
I only have a v1.
I can't imagine how much unrolled self modifying code I can put into 512KB of RAM...
#10
Dude, I'm knee deep into BRAM atm :)
The BRAM starts with a 16 bytes header.
  • 00-03 - Header tag (equals to "HUBM")
  • 04-05 - Pointer to the first byte after BRAM storage
  • 06-07 - Pointer to the next available BRAM slot (first unused byte)
  • 08-0f - Reserved (set to 0).
A BRAM entry is formatted as follow:
  • 00-01 - Entry size. This size includes the 16 bytes of the entry header
  • 02-03 - Checksum. The checksum is the sum of the entry bytes starting from byte #4 (i.e all bytes except the entry size and checksum). The value stored is the opposite of the computed checksum. This way the consistency check only consists in adding the stored checksum and the newly computed one. If this sum is 0, the entry is valid
  • 04-0f - Entry name.
    • 00-01 - Unique ID
    • 02-0b - ASCII name padded with spaces

If I understood what was written in the Develo Book, the bm_files routine of the system card fetches the nth entry (n stored in _al). _bx stores the address where the entry information will be stored (id,name,size). At the end _si will contain the address of the matching entry.
#11
You can use yy-chr to view/edit the VDC dump and save it to BMP.
#12
Cool!
#13
I agree. The code is more readable with square-brackets.
#14
You got me wrong :)
I was meaning pceas.
#15
I would fix the non standard compiler instead.
#16
I started working on a pceas/ca65 stuffs.
The macro syntax is different but you can get something close but not enough to avoid doing the job twice.
Example :
https://github.com/BlockoS/HuDK/blob/master/include/pceas/word.inc
vs
https://github.com/BlockoS/HuDK/blob/master/include/ca65/word.inc
#17
cmd11_Send_Phys_Addr_Broken? is super/really weird...
Do you know if it appears in the other games?
#18
I quickly hacked something.
Labels are now used in opcode arguments.

etripator v0.5 (beta)
#19
Not yet. It's on the todo list.
#20
Yep :

For Gai Flame, I'm using this configuration file for the moment:
[hu7d]
filename=hu7.asm
type=code
bank=0
org=f243
size=d9

update
#21
I'll try to run etripator on some v1.20 games tonight.
#22
Just a side note : the PC Engine Deflemask player thingie is far from being usable :(
#23
Thanks :)
SD card SPI interface is a pain in the harp in general (multiple sector write in particular).
Did you manage to get single sector read working?
#24
I should have said why I need extra RAM.
The extra RAM is only needed if some kind of editor is needed and because I'm lazy :p

Otherwise it's perfectly feasable but you'll need to juggle.
#25
First draft of the technical doc mb128.txt

As for the manager... erm... I'll need to grab a TED v2 for the extra RAM.
#26
I'm currently working on memory base 128 management. I still to figure out one thing or too.
#27
I have coded a command line tile extractor for Pack-In-Video/Namcot games (zipang, marchen maze, obocchama kun, World Jockey). I don't known if all Hudson Soft games are using the same tile encoding scheme.

Unfortunately,  I'm not an expert in (and not very found of) GUI coding but I can help on the encoding/decoding part.
#28
Blame kids and xmas :)
#29
Multiple sector writes are finally working! I still need to add the C "export".
By the way, I tried to compile with the "new" HuC and it's complaining about long lines and some other weird stuffs (why were the underscore removed from _si, _cl and co?).
#30
Yo! Count me in. I can give a hand for hack/code stuffs.

I have some projects going on. The main ones being Nazo No Masquerade and Uchuu Senkan Yamato (yeah Shubi I haven't forgotten about it).
Unfortunately due to life and shit, progresses are sparse.
#31
It's not a hardware bug. It's just that sd cards are a little bit picky about writing.
#32
Long live to Microchip engineers! Thanks to their PIC code, I managed to fix Single Sector write.
Next is Multiple Sector writes.
#33
Good news!
I managed to make disk_write_single_sector work. But there's something weird.
Right after sending the 512 bytes, you write the 2 bytes CRC and read some kind of status. If you do a bitwise and with $1f and get 5, the write is supposed to be ok. Then you wait for the end of the transfer (which is something like while(spi_reg != 0xff) { nop; }).
But in my case, I'm getting $ff when I'm reading the write status...
#34
First things first...HuC complained about some text in the comments. In the end it was a newline issue. I had to add the byte flag to fopen calls in io.c. I can post a patch for the curious ones.

Anyway! It seems that something is missing. pceas complains about an undefined routine called _mem.
Maybe you forgot to add some file? It's called in fat-files-extras.h.
By the way, it feels that something have been eaten from line 432.
#35
Hello there!

I'll resume working on write operation anytime soon. I got busy with demo stuffs...
#36
nop (the coder) told me that the song is the vgm output of deflemask.
#37
If i understand things right, you are looking for a way to get the current offset. I did something similar when i was playing with interrupts.

    ldy #high(HERE)
    lda #low(HERE)
    bne skip
    dey
skip:
    dec A
    phy
    pha

    jmp [vector]
HERE:

It emulates the behaviour of the jsr intruction. This code doesn't work if you put it in a different bank or in ram. mkit is using a cleaner solution.
dummy_interrupt_vector:
                     ; some code
    jsr user_code    ; push pc-1 into the stack an jump to user_code
                     ; the 'rts' in the code pointed by vector will bring us back here
    rti              ; end of the interrupt vector

user_code:
    jmp [vector]     ; let's jump to user defined code

The user defined vector must finish with a 'rts'. As we had a 'jsr' to user_code, the 'rts" will bring us back to the instruction coming after the 'jsr'.

Anyway, in pceas there no keywords to get the current address but you can use a label as a standard immediate value.
#38
I'm using pceas (cvs version) with custom headers. They are in fact a mostly rewritten hucard only version of mkit.
I tried wla-dx but it misses some of the pceas functionalities. And it can be very annoying. But on the other hand, i'ld be cool if pceas has the bank/slot/org/orga commands from wla-dx. It will make things clearer because at the moment you have to do the evil address computation by yourself... and erm... I think I'm going off-topic :)