OASIS development

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
iss
Flight Lieutenant
Posts: 430
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS development

Post by iss » Wed Feb 08, 2017 8:50 am

Wow, full-functional teleport, it's awesome. :)

User avatar
Dbug
Site Admin
Posts: 2268
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Wed Feb 08, 2017 9:56 pm

Symoon wrote:Lucasfilm's Zak Mac Kracken didn't even have such a design for teleportation: it just used a sound and erased or re-drew the hero's sprite.
That's the difference between Elite programmers and wannabees :)

User avatar
coco.oric
Flight Lieutenant
Posts: 382
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: OASIS development

Post by coco.oric » Thu Feb 09, 2017 7:10 am

Nice vids !
coco.oric as DidierV, CEO Member
Image Image

User avatar
ibisum
Squad Leader
Posts: 831
Joined: Fri Apr 03, 2009 8:56 am

Re: OASIS development

Post by ibisum » Thu Feb 09, 2017 9:59 pm

Very nice videos! So much anticipation to play this ...

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Fri Feb 17, 2017 11:09 am

Just a quick note. I have been quite productive lately, and made several new designs (five! and I need a couple more) for the last part of this episode 2. If just debugging such a complex system (with memory management, script interpreting and multi-threading) takes A LOT (nearly 4 hours to hunt and solve the last bug I faced), designing and drawing is my own nightmare.

Here is an example (not finished yet, some details missing, but the room layout is ready)
cahall.png
cahall.png (8.82 KiB) Viewed 758 times
Not that I am not enjoying it and learning many new things, but it takes me an average of 2-3 hours to draw the first version a new room graphic. And then come the zplane masks, and then the objects, and put all the data in disk and in my tables, and test it... Tweaking small details as the walking boxes' borders, animations, other character movements and timings... also takes a lot of time. And it is something that can always be improved, so a never-ending process.

I must confess I considered many times reducing the game to a bunch of dozen rooms and something that could be played in a couple of hours at most. More like a demo than a full game. But I decided not to. For good or bad this is going to take long because it will be a usual-length game. I am going to put a lot of effort in this, because I am enjoying the process and I want (if I can) to keep attention to details and storytelling too.

The engine is quite powerful and permits to do a lot of nice things, so I want to use all of the features available :)

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Wed Mar 01, 2017 10:11 pm

Hi all!

Quite some time since the last update, I know.

The good news is that Episode II is finished at last. There are some small things here and there that need tweaking, some texts, some descriptions, default messages for logical, but ineffective actions, and so on. And of course all the testing. I think the result is quite interesting and you'll like it.

I have to make some preliminary tests and then I'll send it to some people for beta-testing.

The bad news is that my saving code is not working on real floppies. This is quite frustrating: strange long loading times, a lot of work to do to make it work on the Telestrat, sounds get distorted and so on.. all of those with the additional cumbersome and time wasting process for testing. I am even tempted to substitute the read/write sector routines for my old code, using irqs, while keeping the nice on the fly decompression. But that is also a long and error-prone process.

Anyway, the symptoms: the code attempts to write 7 sectors with the game status. A disk icon is drawn and flickers in different colors each time a sector is written. It is only displayed once in red and the Oric freezes, which means that only one sector is being written. In fact the icon stays onscreen, so the code is not clearing the image (which happens when the write is finished). However the data is written, because the engine looks for the presence of a saved game by loading one sector and checking for a fixed value in a byte and it is there.

Of course it works perfectly under emulation.

My code is based on the ReadSector:

Code: Select all

WriteSector	
__fdc_writesector
	lda #CMD_WriteSector
__fdc_command_w
	sta FDC_command_register

	ldy #0
loop_write_sector
__fdc_drq_w
	lda FDC_drq
	bmi loop_write_sector
__fdc_data_w
	lda (ptr_data),y
	sta FDC_data
	iny
	bne loop_write_sector

__fdc_status_w
	lda FDC_status_register
	and #$7c ; Chema changed the original vaue: 1C
	bne __fdc_writesector ; Chema: If error repeat forever:
	jmp ClearLoadingPic
So I think the problem is that the status register returns an error. But the disk led is not kept on and no noise is heard from the floppy drive (no activity, it seems). Am I doing something wrong when checking the status? Additional question: do the IRQs need to be disabled? In the ReadSector routine they are disabled before reading a sector, then they are enabled again.

Edit: Mmm maybe the thing is that some delay is needed after the las write to the data sector and checking the status... Worth trying. I'll let you know when I have some time to do the tests.

User avatar
iss
Flight Lieutenant
Posts: 430
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS development

Post by iss » Thu Mar 02, 2017 12:55 am

About your additional question: I think that read/write code will never work if IRQ's are enabled.
The minimal part of code which have to run with disabled IRQ's is:

Code: Select all

	php
	sei
	ldy #0
loop_write_sector
	lda FDC_drq
	bmi loop_write_sector
	lda (ptr_data),y
	sta FDC_data
	iny
	bne loop_write_sector
	plp
Here I'm using php/plp instead implicit sei/cli, because this allows nested sei's.

User avatar
Dbug
Site Admin
Posts: 2268
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OASIS development

Post by Dbug » Thu Mar 02, 2017 8:01 am

Chema wrote:
Wed Mar 01, 2017 10:11 pm
Additional question: do the IRQs need to be disabled?
As far as I know, you can have the IRQ enabled... BUT it's when using IRQ based loading (ie: the byte is fetched in the IRQ routine and then you return immediately).
If you are using the bit polling method, IRQ should be disabled during all the loading and writing.

In my demos I keep enabling/disabling the irqs, which makes the music play a bit wobbly, but it kind of work.

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Thu Mar 02, 2017 9:06 am

Thanks guys! I already have the IRQs disabled, just wanted to check. The thing is that I think I need to wait until the last read operation finishes before checking the status. I don't know how I forgot that. I must have a look at the data sheet to check how this is done (maybe another DRQ, maybe some other bit... on my old code it was an IRQ triggering...).

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Thu Mar 02, 2017 11:31 pm

Okay got the saving working on real floppies. And it is quite fast. It must have been some trouble with reading the status when the command had not finished or maybe something with the interrupt disable flag not being set (it was a bit of a nightmare). I cleaned up all that and only keep IRQs disabled during the write and read operations while streaming the bytes of a sector to prevent lost data errors.

My routine is now something such as this:

Code: Select all

WriteSector	
__fdc_writesector
	lda #CMD_WriteSector
__fdc_command_w
	sta FDC_command_register
	; Read the sector data
	sei
	ldy #0
loop_write_sector
__fdc_drq_w
	lda FDC_drq
	bmi loop_write_sector
	lda (ptr_destination),y
__fdc_data_w	
	sta FDC_data
	iny
	bne loop_write_sector
	cli
	
	; Okay we cannot poll $318 for completion. We have to use the busy bit
	; again, but we also need the value of other bits to check for errors.
	; I am going to suppose that we don't need to wait 24us after the write to
	; the command register, because we have been writing 256 bytes to disc, and
	; it was enough time.
__fdc_status_w
	lda FDC_status_register
	bmi __fdc_status_w	; If s7 (NOT READY) is not zero, wait (S7= /READY OR MR).
	and #$7c ; Chema changed the original vaue: 1C
	bne __fdc_writesector ; Chema: If error repeat forever:
	rts
Still reading data from compressed files is very slow. There is a huge difference when reading uncompressed data. Or I deduced for the seldom occasions in which the disk icon flickers quickly as expected. Also there is a quite ugly distortion of the sound effects if disk is accessed. I need to figure how to reduce this to the minimum... even if I have to wait for the sound to finish before starting the disk operation.

Edit: Here are some pics of the game running on my real Oric from a real floppy in my CRT TV :)
IMG_20170302_224302.png
IMG_20170302_230930.png
IMG_20170302_230340.png

User avatar
iss
Flight Lieutenant
Posts: 430
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OASIS development

Post by iss » Fri Mar 03, 2017 1:39 am

No way, this pictures are from PhotoShop! ;) ... congrats it looks amazing.

About the writing code - IMO, waiting S7 (NOT READY) is not correct, you should wait S0 (BUSY):

Code: Select all

__fdc_status_w
	lda FDC_status_register
	lsr
	bcs __fdc_status_w	; If S0 (BUSY) is not zero, wait
	asl
	and #$7c ; Chema changed the original vaue: 1C - yes, 7C is better than 1C :)
	bne __fdc_writesector ; Chema: If error repeat forever:
	rts
Does that make sense or I'm wrong?

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Fri Mar 03, 2017 9:05 am

About the BUSY signal, yes. That was the one I was going to poll, but then I thought 'the READY input is flagged by the floppy drive when it's ready to receive a new command, so maybe it is also valid here'. As all it takes is a bmi to test... and it worked!

But I do think that the BUSY bit (s0) should be tested. It would be much better to enable IRQs in the controller (even if they are disabled in the CPU) and check the value of bit 7 in <s>$318</s>$314, but that meant too many changes.

EDIT: I am not sure why I keep on saying $318 instead of $314. The former holds the DRQ status, and the latter the INTRQ state. Sorry.
EDIT2: Why this forum does not support strike out <s></s> BBCode?

User avatar
ibisum
Squad Leader
Posts: 831
Joined: Fri Apr 03, 2009 8:56 am

Re: OASIS development

Post by ibisum » Fri Mar 03, 2017 3:12 pm

This Looks AMAZING!

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Fri Mar 03, 2017 6:23 pm

I changed the code to use the BUSY flag and also corrected some other small things and tested on a real Oric. Everything seems to work fine. My disks or my floppy drive seems to have a few errors reading data (you hear the motor trrrrrr sound from time to time).

One thing I tested was creating a disk without compression. The result is there is no noticeable improvement in speed when loading things. I am changing the color of the disk picture at each sector load. This is done before the PrepareTrack call (which performs the SEEK command) and is followed by the actual data read loop. Clearly the disk icon is there without changing colors for too long, what made me think it was due to the head missing the next sector and needed to wait for a full turn.

Now I wonder if something is wrong with the code that performs the SEEK command. Any ideas?

User avatar
Chema
Game master
Posts: 1910
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OASIS development

Post by Chema » Wed Mar 15, 2017 11:35 am

Hi again.

Just a quick message to let you know I have finished the translation of the game to Spanish. Yeah, it was a loooong tedious process (many files to touch, a lot of text to translate) but as there are some Spanish people around with Orics (and without Orics!) who wanted to play the game, I thought it would be a nice touch.

I also finished Episode II and, thought I have to tweak a few things yet) I sent the game to a couple of people for alfa testing. I wanted to have new opinions about playability, puzzle design, graphics and animations and so on with this new episode and in Spanish.

And I have already started jotting down some notes about the final episode. Let's see how it develops.

Stay tuned!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests